[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-v6ops-addcon-00.txt
- To: "'Brian E Carpenter'" <brc@zurich.ibm.com>, <v6ops@ops.ietf.org>
- Subject: RE: I-D ACTION:draft-ietf-v6ops-addcon-00.txt
- From: "Gunter Van de Velde \(gvandeve\)" <gvandeve@cisco.com>
- Date: Tue, 13 Jun 2006 10:56:05 +0200
- Authentication-results: sj-dkim-3.cisco.com; header.From=gvandeve@cisco.com; dkim=pass ( sig from cisco.com verified; );
- Dkim-signature: a=rsa-sha1; q=dns; l=1874; t=1150188966; x=1151052966; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gvandeve@cisco.com; z=From:=22Gunter=20Van=20de=20Velde=20\(gvandeve\)=22=20<gvandeve@cisco.com> |Subject:RE=3A=20I-D=20ACTION=3Adraft-ietf-v6ops-addcon-00.txt; X=v=3Dcisco.com=3B=20h=3DC4ierq7u9P9t+13qZg9RdLdZPDs=3D; b=tbcYeWoUT4CFlfqE4Mqcst+B8Bmf7MMaabe4AmpHzXpsKmLsZHittL6rv4ZgmwvG5E+jWza7 RXo9I/7g7QzsqhOFxfCBxjK9hfrxE+y/3yMadzlHYqLN0fWUhX2/AewQ;
- In-reply-to: <448E684C.8080507@zurich.ibm.com>
- Reply-to: <gvandeve@cisco.com>
Hi Brian,
Many thanks for this swift response.
See inline GV>
> 1. Introduction
>
> The Internet Protocol Version 6 (IPv6) Addressing Architecture [23]
> defines three main types of addresses: unicast, anycast and
> multicast. This document focuses on unicast addresses, for which
> there are currently three principal allocated types: Global Unique
> Addresses [12] ('globals'), Unique Local IPv6 Addresses [22] (ULAs)
> and 6bone address space [3].
It's a bit odd to include 6bone space as a "focus" item since all you say is
that it's history.
GV> maybe a rewording would help here. The intention was to mention that the
focus area
is unicast addresses. The address ranges were just given as the three
principal allocated
types.
> 2.2. Unique Local IPv6 Addresses
...
> Because a ULA and a global site prefix are both /48 length, an
> administrator can choose to use the same subnetting (and host
> addressing) plan for both prefixes.
The RIRs are moving away from a rigid /48 policy. It would be safer to start
this sentence with "When" instead of "Because".
And on the same topic...
GV> sounds ok to me.
> 2.4. Network Level Design Considerations
I suggest adding a bullet at the end of this section along these
lines:
o It is possible that as registry policies evolve, a small site
may experience an increase in prefix length when renumbering,
e.g. from /48 to /56. For this reason, the best practice is
number subnets compactly rather than sparsely, and to
use low-order bits as much as possible when numbering subnets.
In other words, even if a /48 is allocated, act as though
only a /56 is available. Clearly, this advice does not apply
to large sites and enterprises that have an intrinsic need
for a /48 prefix.
GV> ok.
Groetjes,
G/