Pekka, As I am packing for a 3.5 week trip, I don't have time to go into full detail. I mostly disagree with you on the big points (your smaller points are fine), but these are not new arguments anyway.
> 1) specifying just one allocator to the end-sites; this is always bad > and prone to create monsters such as ICANN. That's unfair language. ICANN is not a monopolist. > It seems like that the model should be provided to support > enough registries (e.g. 2 bit = 4 or 3 bits = 8). It might indeed be wise for IANA to only hand out 1/8 of the space to the first registry - that would leave flexibility to create more if competition proved necessary. > 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 do agree this is badly phrased - it isn't the *protocol* that does the filtering, it's the default router config. Just as NATs are shipped with an effective "deny all" configured, IPv6 routers should be shipped with "deny FC00::/7" configured. And it's because so many corporate security solutions now depend on that effective "deny all", much as you and I may hate it, that we need this. You can certainly deny by default. A site that wants to use FC00::/7 internally or on VPNs can enable it where needed. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM *** I will be on vacation February 3-25, 2004 *** Pekka Savola wrote: > > On Mon, 26 Jan 2004, Brian Haberman wrote: > > This is the start of an IPv6 working group last call on: > > > > > Title : Unique Local IPv6 Unicast Addresses > > > Author(s) : R. Hinden, B. Haberman > > > Filename : draft-ietf-ipv6-unique-local-addr-02.txt > > > Pages : 16 > > > Date : 2004-1-21 > > Below are my comments. I don't think we really need this kind of > stuff, but as local addressing seems to have been taken as granted > already, I don't argue on those grounds. (However, at some point I > believe someone will make you insert a better applicability statement > on where to (not) use the local addressing.. you could very well try > to do it now.) > > As for the rest, I have a major concern on picking just one registrar > for the central allocations. I also have major deployment and > implementation concerns with "default deny" policies; they seem to be > unacceptable or unfeasible. The security of local addressing must be > based on the fact that the site administrator has toggled on a switch > or configured the access-lists -- NOT on protocols having to filter > out the addresses, or having some kind of default access-lists > magically deny all the traffic at vague site borders. > > Below.. > > substantial > ----------- > > 1) specifying just one allocator to the end-sites; this is always bad > and prone to create monsters such as ICANN. > > 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). > > 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. > > 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. > > 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. > > 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 :-) > > 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. > > 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) > > 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. > > 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/ ? > > 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. > > editorial > --------- > > ==> please include the IPR and copyright sections if possible.. > > INTERNET-DRAFT R. Hinden, Nokia > January 20, 2004 Brian Haberman, Caspian > > ==> s/Brian/B./ (same style :) > > This document defines an unicast address format that is globally > > ==> s/an/an IPv6/ > > interface ID 64-bit IID as defined in [ADDARCH]. > > ==> s/IID/interface ID/ > > prefix and Global ID field length. There is a direct tradeoff > > ==> s/Global ID/global ID/ -- or at least be consistent whether it starts > with the upper case in the middle of sentence or not (the same with a few > other places) > > needlessly. A reasonable way of evaluating a specific field length > is to compare it to a projected 2050 world population of 9.3 billion > [POPUL] to compare the number of resulting /48 prefixes per person. > > ==> s/to compare/and/ (the latter "to compare") > > Prefix Global ID Number /48 Prefixes % of IPv6 > Length Prefixes per Person Address Space > > ==> s/Number/Number of/ > > ==> IPv6 Address Space goes beyond 72 words/line, which is bad. > > A very high utilization ratio of these allocations can be assumed > because no internal structure is required in the field nor is there > any reason to be able to aggregate the prefixes. > > ==> sounds soooo awkward, maybe reword: > > A very high utilization ratio of these allocations can be assumed > because the global ID field does not require internal structure, > and there is no reason to be able to aggregate the prefixes. > > ... > The authors believes that a /7 prefix resulting in a 41 bit Global ID > > ==> s/believes/believe/ > > exhausted. If more than this was needed, then additional IPv6 > address space could be allocated for this purpose. > > ==> s/was/were to be/ ? > > should not be assigned sequentially or with well known numbers. This > to ensure that there is not any relationship between allocations and > > ==> s/This/This is/ > > duplicate assignments. The local assignments are free and do not > need any central coordination or assignment, but have a lower (but > > ==> remove "are free and" due to removing the 10 euro charge text? > (without coordination or assignment, there certainly can't be any > fee to them :) > > This is easiest to accomplish if there is a single source of the > assignments. > > ==> sounds funny, maybe s/of/for/ ? > > addition to web based registration they should support some methods > like telephone, postal mail, fax, telex, etc. They should also > > ==> perhaps it has been long enough to be able to remove "telex" from the > list :-) > > It is escrowed to insure there are no duplicate allocations and in > > ==> s/insure/ensure/ (the same elsewhere) > > makes it easy to get a prefix with out the need to contact an > > > ==> s/with out/without/ > > is adequate for sites planning a small to moderate amount inter-site > communication using locally generated global IDs. Sites planning > > ==> s/amount/amount of/ > > [ICMPV6] Conta, A., S. Deering, "Internet Control Message Protocol > (ICMPv6) for the Internet Protocol Version 6 (IPv6) > Specification", RFC1885, December 1998. > ==> old reference. > > [RFC2026] Bradner, S., "The Internet Standards Process -- Revision > 3", RFC 2026, BCP00009, October 1996. > > ==> remove this, unused reference. > > [RTP] Schulzrinne, H., S. Casner, R. Frederick, V. Jacobson, > "RTP: A Transport Protocol for Real-Time Applications" > RFC1889, January 1996. > > ==> use RFC3550 instead. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [EMAIL PROTECTED] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
