Do you have any working code ? Also, have you considered moving your mailing list to an IPv6 transport ? ...would there be any users ?
----- Original Message ----- From: "Margaret Wasserman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, April 03, 2003 6:01 AM Subject: My Thoughts on Site-Locals > > I have a few thoughts to share on site-local addressing... > > Many people have written to the list lately stating that site-locals > should be retained for (at least) one of these two reasons: > > - Numbering for disconnected networks. > - Access control. > - Numbering for intermittently-connected networks. > > I do consider these things to be very important, but I do not > consider site-local addresses to be the best architectural solution > to these problems. > > Site-local addresses have properties that are not needed to address > these problems, and that cause problems for routing protocols and > upper-layer protocols, such as: > > - Ambiguity (requires zone ID to disambiguate). > - Need to retain site "convexity". > - Single level of nesting (you can't have a further access- > controlled site within a site). > - Special address selection handling required at the IP > layer and in applications. > - Places the knowledge of private addressing in all implementations, > instead of keeping the knowledge of routing boundaries > constrained to the infrastructure (routers, firewalls, > etc.) > > Using random addresses for disconnected sites was proposed as an > alternative, but that is not the only alternative. There are, in > fact, two superior alternatives that do not require any standardization > work by the IPv6 WG (or any other IETF WG): > > - Enterprises could use part of their /48 as private > addresses and filter at private borders. This > is superior to site-locals because: > > - It allows nesting of private areas. > - The owner of local addresses can be identified. > - Non-ambiguous -- if sent outside the local area, > they are unreachable and won't point to > the wrong network or node. > - Doesn't require special handling on end-nodes > or by applications, etc. > > - Registries could offer private address allocations to > individual enterprises/people. This is also > superior for the same reasons listed above. > > Access control is also useful, and a simple form of access control will > be needed in IPv6. However, site-local addresses are a poor form of > access control for two reasons: > > - Site-local boundaries need to be at routing area > or AS boundaries (not convenient). > - Site-local areas cannot be nested. > > So, you can't have a site-local access control boundary for your corporate > site, AND a site-local access control boundary that only allows the marketing > department to use the fancy printer. > > Both Steve Bellovin and Brian Zill have proposed superior access control > mechanisms based on information being passed in router advertisements, and > I think they plan to combine their proposals into a single, maximally > beneficial, form. > > The intermittently-connected site problem is often raised as a reason for > site-locals. This is an interesting problem, and it would be very good > to solve this problem, but site-locals do not provide a complete solution. > And, recent models for site-local usages (including "moderate" and > "limited") don't provide a solution for this case at all, as they would > reverse the preference for site-local addresses over global addresses > in the address selection rules. > > So, while I think that the IETF needs to figure out a way to address this > type of network, site-locals may not be the best way to do it, as they > come with substantial costs for all nodes, and don't fully solve this > problem. > > Just my thoughts... > > Margaret > > > > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
