[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-v6ops-addcon WGLC
On Sun, 3 Dec 2006, Fred Baker wrote:
This is to announce a working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-addcon
Please read the draft at this time, noting spelling or wording issues to the
authors and substantive issues to the authors copying the list.
Working Group last call will close in two weeks.
Sorry for being a few days late, but writing up the comments took a
while. I think the doc is in pretty good shape.
I'd recommend moving the case studies to an appendix.
Substantial
-----------
A multihomed
host may thus have two addresses, one per prefix (provider), and
select source and destination addresses to use as described in that
RFC. [...]
==> it seems that more text is required of this; maybe an additional
paragraph with pointers. Specifically, making address selection and ingress
filtering work at the border requires some action from the site
administrator as discussed in a couple of Internet-drafts out of multi6 and
shim6 WGs. The current text makes this sound a bit too easy..
An allocation of a prefix shorter then 64 bits to a node or interface
is bad practice. The shortest subnet prefix that could theoretically
be assigned to an interface or node is limited by the size of the
network prefix allocated to the organization.
==> However, there is at least one valid case of a prefix shorter than /64:
the 6to4 pseudo-interface which should have a /16. Maybe this should be
mentioned for completeness.
In addition it is discouraged to assign a matching embedded-RP IPv6
address to a device that is not a real Multicast Rendezvous Point.
==> personally, I don't see a major problem with this. No application or
host should (IMHO) have an assumption that if the RIID is pingable
(or some other similar criterion), it would be an RP. Personally I wouldn't
assign RIID = 1 (which probably the most common Embedded-RP RIID value used)
to a host though, but that's for other reasons..
3.3.4. /126 addresses
The 126 bit subnet prefixes are typically used for point-to-point
links similar to the RFC3021 [5] recommendations for IPv4.
==> I'm not sure if RFC3021 is directly comparable to v4 /31, especially
because /126 allows for more addresses. /126 seems to be more like a v4
/30. Given that the use of /31 required modifications to specifications,
I'm not sure how relevant that is in this context given that there is no
shortage of v6 addresses for p2p links.
Basic design decisions for the exemplary Service Provider IPv6
address plan regarding customer prefixes take into consideration:
o The prefixes assigned to all customers behind the same LER (e.g.
LER or LER-BB) are aggregated under one prefix. This ensures that
the number of labels that have to be used for 6PE is limited and
hence provides a strong MPLS label conservation.
...
When the IPv6 customer address pool of a LER (or another device of
the aggregation network - AG or RAR) is exhausted, the related LER
(or AG or RAR) prefix is shortened by 1 or 2 bits (e.g. from /38 to
/37 or /36) so that the originally reserved growing zone can be used
for further IPv6 address allocations to customers. In the case where
the growing zone is exhausted as well a new prefix range from the
corresponding pool of the next higher hierarchy level can be
requested.
==> These two points in particular raise the question of "umm.. what about
renumberability?" If a customer changed the RAR, LER or whatever, would it
need to renumber? If a RAR, LER, etc. would need to be split up (e.g., due
to needing a bigger device), would some need to renumber? Etc. You already
discuss this in 5.2.3.3. but this at least needs to be referred to, if not
discussed a bit (i.e., how does that affect the design?). Today
in many cases, e.g., customer ADSL lines, customers will need to renumber
but corporate customers (even if they used the same ADSL infrastructure)
wouldn't. This seems the minimum model that needs to be supported by IPv6
deployments IMHO.
Editorial
---------
==> In abstract, rephrase two instances of "draft" (no longer applicable when
this is an RFC)
The address assignment considerations are analyzed separately for the
two major components of the IPv6 unicast addresses, namely 'Network
Level Addressing' (the allocation of subnets) and the 'Subnet Prefix'
(address usage within a subnet).
==> 'Subnet Prefix' seems to be a misnomer in this context, as it usually
refers to a prefix, not the interface-ID part of the address. Was this a
typo?
Finally the document provides two examples of
successfully deployed address plans in a service provider (ISP) and
an enterprise network.
==> I'd remove "successfully" because these deployments haven't really seen
the "test of time" yet, i.e., we don't yet know if the planning has been
successful because IPv6 hasn't been thoroughly deployed yet.
However
ARIN is now piloting PI address space allocations, subject to
customers meeting certain requirements.
==> no longer 'piloting' I think..
This format implies that when selecting subnet prefixes longer then
64, and the bits beyond the 64th one are none-zero, the subnet can
not use embedded-RP.
==> s/none/non/
For the Mobile IPv6 early trails, we have allocated one prefix for
==> s/trails/trials/
is recommended. (Note: A strong aggregation e.g. on POP,
aggregation router or LER level limits the numbers of customer
==> spell out 'LER'.
adapt changes that are injected from the customer side. This
covers changes to addressing architecture or routing topology that
are triggered from for instance the raising needs of the customers
regarding IPv6 addresses as well as changes that come from
==> s/raising/growing/ (or 'rising') ?
* A pool (e.g. /24) for satisfying the addressing needs of real
"big" customers (as defined in 5.2.2.1 sub-section A.) that
==> s/real/really/ (or something like that)
coded using a /64 prefix. (Note: While it is suggested to chose a
/48 for addressing the POP/location of the SP network it is left to
==> s/chose/choose/
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings