Hello, A few comments on this draft; apologies about a very quick read only.
In general I agree with most conclusions in the draft. I don't like site locals at all, because they're used wrongly. However, I can understand why people want to use them .. the perceived ease for itself (but making it more difficult for _others_). Substantial comments: Site-Border Node An IPv6 node with interfaces in more than one site ==> I note that the definion is different from e.g. what Bob Hinden uses in his drafts; otherwise put, would sl-impact be significantly changed if there was a subclass of SBN's: those interfacing one site and "no-site". Some of the complexities of IPv4 NAT are avoided by the fact that IPv6 SBRs do not translate site-local addresses into global addresses. Instead, traffic to and from site-local addresses is dropped at site boundaries, with an appropriate ICMP error message. and: SBRs must ensure that site-local traffic is not forwarded outside of the site. This requires complex processing in the forwarding engine of an SBR. This is another situation where some have argued that the complexity is already required for link-local addresses, but again that is not completely true. All IPv6 routers will need to check all forwarded packets to determine if either the source or destination is link-local. If so, the packet will be discarded and an ICMP "scope exceeded" error message will be generated. ==> perhaps this ICMP message is a by-product of scoped address architecture, but sure isn't defined in addrarch or ICMPv3 documents. Some people have commented that the same problems exist for link- local addresses, but this is not entirely true. Link-local addresses can use an existing identifier, the interface ID, as their qualifier, while site-local addresses require the configuration of an artificial zone ID. Also, it is not expected that link-local addresses will be put in the DNS, or passed around by applications running on multi-link networks. ==> the middle sentence is not accurate. It is typical that many interfaces have the same link-local interface ID (e.g. tunnel interfaces). So, to maximize the chance that connections will survive and that packets will continue to reach their intended destinations when a MIPv6 node roams, MIPv6 nodes should not configure site-local addresses and should not use site-local destination addresses, perhaps even when global addresses are unavailable. This would require that MIPv6 nodes ignore site-local prefixes in IPv6 router advertisements, and that a different set of default address selection rules be used on MIPv6-capable nodes than is currently defined for other IPv6 nodes. ==> my belief is that in mobile-IP case, it should be enough that MIPv6 nodes ignore all site-local addresses that are not guaranteed to come from the Home Agent or while at home. Whether there would be problems with this is another issue. 7.5 Transport Protocol Issues Some transport protocols, such as SCTP and SIP, involve passing the ==> strictly speaking, is SIP a transport protocol? I thought it uses UDP throughout. 8.2.1 Benefits for Newly-Connected Sites When an isolated site gains connectivity to the IPv6 Internet, it could be useful for nodes to maintain their site-local addresses, in addition to their new global addresses. This would allow long- lived connections to remain active, and would prevent cached, logged or stored IP address information from becoming invalid. ==> IMO, this is relatively questionable benefit. Obtaining Internet connectivity is a one-time event. Typically this could be considered as a "flag day" (or flag hour/minute). Whether long-lived site-local connections survive this even is IMO completely irrelevant. IPv6 site-local addressing adds significant complexity and cost to IPv6, and it does not provide sufficient benefit to justify that cost. Every benefit of site-local addressing can be better provided by simpler, less problematic, and less expensive mechanisms. ==> [referring to GUPI-like solutions in above]. I wouldn't go so far as to say other mechanisms are necessarily "less expensive". It's more of a question on who pays the cost. App developers, Internet architects, people trying to figure out how to make routing GUPI work, ISP's operating routers, etc.etc. In a perfect world, GUPI would be a nice solution. But alas, we're far from the perfect world, and making globally routable GUPI's work could be more work that we could ever imagine, using current architectural principles. Editorial: ==> the numbering of chapters usually starts with introduction. SBRs do not modify addresses in forwarded IP headers, so the use of IPv6 site-local addresses does not conflict with end-to-end security or peer-to-peer communication. ==> s/does/do/ provide split DNS service for customersÆ site-local addresses. ==> fix weird character This practice has not been documented, however, and there may be flaws in this approach, particularly in the presence of Mobile IP, as described in section 7.4 ==> s/7.4/7.4./ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------