Thanks for the comments. I will respond to the substantial issues and semi-editorial in your email. The editorial ones look fine and should be to include them in the next version of the draft.
substantial -----------
1) specifying just one allocator to the end-sites; this is always bad and prone to create monsters such as ICANN.
I don't see how the current text would "create monsters such as ICANN". All we are talking about is assignment of local prefixes. Somewhat more limited scope than what ICANN has.
It seems like that the model should be provided to support enough registries (e.g. 2 bit = 4 or 3 bits = 8). Just to make sure that the customers can pick someone else's service unless they aren't satisfied with an organization, so that there is some incentive not to have too high charges, to avoid the claims of building monopolies who get free money for numbers, etc.etc. Unless you have instructions in mind for IANA who should have this registry monopoly, there should probably be multiple registries in the only one of them screws up in a major way (e.g., compare to the mess with .com zone by verisign).
The text in the IANA considerations section calls for the IANA to set up a "allocation authority" for the centrally assigned ULA prefixes. The exact details of how to do this (i.e., one or many organizations doing the assignments, who it is, etc., etc.) are left to the IANA as long as they meet the requirements stated in the document.
I am comfortable with the IANA doing this in a manner that will be beneficial from the community. It is also, of course, out of scope for the IETF to specify more than the allocation requirements, which this document does do.
We have learned from past experience it's not wise to over specify when asking the IANA to do address allocation. I think the current text is about right in this regard.
Also, if the resulting allocation authority becomes too onerous for some people, they can use the locally assigned prefixes. No one is forced to use the central allocations.
2) The specification requires that routing protocols special-case these prefixes by MUST filtering them. This is unacceptable, and should be removed. Any filtering should be done by the sites themselves. Note that running any other protocol than BGP is not feasible anyway to be run over administrative domains (exclusing provider-provisioned VPNs, maybe, but those are special case anyway), so we can pretty much limit the discussion to BGP. Which is pretty trivial, because 1) why would the ISP advertise such prefixes, and 2) why would the site not filter out stuff it doesn't want.
Any routing protocol that is used between sites MUST filter out any incoming or outgoing Local IPv6 unicast routes. The exception to this is if specific /48 IPv6 local unicast routes have been configured to allow for inter-site communication.
I agree this could be stated better. I think it would be good to change it to "Any router that is used between sites....", as it is not the routing protocols doing the filtering, but the router based on it's configuration. The requirement is that the FC00::/7 is filtered by default by routers at the site boundary. As Brian Carpenter pointed out if there is a filter for this prefix configured by default in all routers, it does no harm as sites that wish to use these addresses would add more specific routes that would override the default filters for these more specific prefixes.
If BGP is being used at the site border with an ISP, filters MUST be installed by default in the BGP configuration to keep any Local IPv6 address prefixes from being advertised outside of the site or for these prefixes to be learned from another site. The exception to this is if there are specific /48 routes created for one or more Local IPv6 prefixes.
3) Similar to the above, there are some particularly inpractical issues with site-border security:
Site border routers SHOULD install a black hole route for the Local IPv6 prefix FC00::/7. This will insure that packets with Local IPv6 destination addresses will not be forwarded outside of the site via a default route. Site border routers SHOULD respond with the appropriate ICMPv6 Destination Unreachable message to inform the source that the packet was not forwarded [ICMPV6]. This feedback is important to avoid transport protocol timeouts.
Site border routers and firewalls SHOULD NOT forward any packets with Local IPv6 source or destination addresses outside of the site unless they have been explicitly configured with routing information about other Local IPv6 prefixes. The default behavior of these devices SHOULD be to filter them. Site border routers SHOULD respond with the appropriate ICMPv6 Destination Unreachable message to inform the source that the packet was not forwarded.
.. this is inpractical, and should be reworded. The site border routers cannot know that they are site-border routers, so these checks cannot be implemented. What you can do is state that a toggle SHOULD be implemented and when enabled on an interface, it would apply these kind of restrictions to it. But the point is that you WILL need administrator action. "Deny by default" just is not practical approach here, because you don't know that you should be denying these by default.
I don't agree. As stated above if the /7 prefix is filtered by default, it does no harm. But I think changing the text to make it clearer that these routers should be configured to do this filtering would make the text clearer.
Additionally, domain border routers connecting autonomous systems throughout the Internet SHOULD obey these recommendations for site border routers.
==> as for this, I have no idea what this even tries to say, so it requires rewording.
It is trying to say that routers that connect autonomous systems also be configured to do this filtering. Even if they are not at site boundaries. How about:
Routers that maintain peering arrangements between Autonomous
Systems throughout the Internet SHOULD obey the recommendations for
site border routers unless configured otherwise.semi-editorial --------------
2) Obtain an EUI-64 identifier from the system running this algorithm. If an EUI-64 does not exist, one can be created from a 48-bit MAC address as specified in [ADDARCH]. If an EUI-64 cannot be obtained or created, a suitably unique identifier, local to the node, should be used (e.g. system serial number).
==> hopefully the centrally assigned global IDs don't use their (single) computer's EUI-64 in the generation :-)
I don't think this is a problem. Every time the algorithm is run the time would change resulting in a new distinct allocation. The MD5 hash guarantees it.
4) Compute an MD5 digest on the key as specified in [MD5DIG].
==> security folks have been pushed for the use of SHA-1 because it's more collision-proof. It doesn't matter much in this specific context, but at least nobody would object if you changed this to using an SHA-1 digest.
As you said, "it doesn't matter...".
Site border routers SHOULD install a black hole route for the Local IPv6 prefix FC00::/7.
==> I think you mean "a reject route" ? (or a "discard" route might also work OK)
I agree this should be changed to a "reject route". Mukesh Gupta also pointed this out during the discussion of the new ICMPv6 destination unreachable codes.
For future study names with Local IPv6 addresses may be resolved inside of the site using dynamic naming systems such as Multicast DNS.
==> this seems irrelevant and should be removed; above, it already states someting general about local naming systems.
I don't see it doing any harm either.
Local IPv6 addresses, like global scope unicast addresses, are only assigned to nodes if their use has been enabled (via IPv6 address autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually) and configured in the DNS.
==> "and configured in the DNS" is not requirement and is irrelevant; should be removed?
assign them. In order for a node to learn the Local IPv6 address of another node, the Local IPv6 address must have been installed in the DNS.
==> s/DNS/DNS or another naming system/ ?
Thanks. Both changes are fine.
11.2 Disadvantages
==> Add to disadvantages:
- Instead of using global unicast addresses inside the sites, the sites may be tempted to start using Local IPv6 addresses excessively, instead of using global unicast addresses and reachability restrictions such as firewalls or access control lists
I think this is out of scope for this document.
Thanks again for your comments.
Bob
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
