I would like to comment on the IPv6 assignment and allocation policy document 1. Terminology. ------------------- I would suggest that this document use the same terminology as the one used in the various IPv6 related RFC, e.g. site local addresses instead of private addresses Also in section 2.2.3, this document refers to 80 bits available for addressing end sites. I would suggest to say at this point that this is 16 + 64 bits. Same total, but the usage is different. 2. Sites and /48 prefixes ------------------------------ I would like this document to define precisely sites. This will make it clear who can (or not) claim a /48 prefix. The document says in section 4.2.1: Only end-user organizations with a need to create subnets in their network should be assigned a full /48. Dial-up lines are considered part of the ISP's infrastructure and should be assigned from the SLA ofthat ISP. I disagree there. The network in my house may be composed of several subnets and still be connected to my ISP via dial-up. (again, we have to define precisely sites) All end-user organization requesting to be a site should get a /48. Address conservation is good practice, but, there, it's asking too much. 3. 80% Requirements for next allocation -------------------------------------------------- in 4.1.3: Once an organization has used 80% of the sub-TLA address space, the organization may contact the Regional IR in its region to request that another range of addresses be allocated I would suggest the document to be more precise about this. This can not be 80% of the all address space of the sub-TLA. A sub-TLA being /35, the total address space is 103 bits long! So, there must be a limit somewhere, for example say it's 80% of the address space in between bit 36 and bit 48. This is correct if a sub-TLA is only servicing sites and not NLAs. If a sub-TLA is servicing NLAs, requesting that all NLAs must use 80% of their address space before the sub-TLA may ask for a full TLA is, IMHO, too strong a requirement. I fear that sub-TLA will then be reluctant to allocate NLA. 4. Router interfaces ------------------------ in section 3.2: All router interfaces are required to have at least one link-local unicast address or site-local address. Site-local will be used for all point-to-point links, loopback addresses, and so forth. As these are not required to be visible outside the site's network, they do not require public address space. Interfaces are required to have a link local address. Not site local. Their use is at the discretion of sites. Some may like them, some not. For administrative reasons, as site borders are often crossed, they are valid cases where router interfaces (and point-to-point links) MUST have global addresses. If I want to ping , from my host, to a router I'm responsible for, on one particular interface and if that router in not within my site borders, I need to find a global address for that particular interface. Any global unicast address space assigned must not be used for the link-local or site-local purpose as there is reserved address space for these addresses. Again, I disagree. This is NOT because two hosts are within the same site that they MUST use site local addresses. This requirement is not acceptable. Some sites may want to implement this, some not. It requires a lot of techniques to do it, including source address selection, DNS tricks and others. 5. General comments -------------------------- This document is focusing heavily on address conservation. Learning IPv4 mistake is a reasonable goal, but IPv6 addresses are so structurally different from IPv4 ones that address conservation should not be so restrictive. Also, the document specificaly ask that all special SLA request MUST be approved by the regional registries. IMHO, those issues should be better resolved at a lower level, NLA and/or SLA. Multi-homing will be more and more frequent. The way ISP will implement multi-homing in IPv6 may have a big impact on aggregation. I would like to see a section on this particular topic in this document. - Alain Durand.