Let me try an rephrase my question. I would like to know if there is consensus on the architectural view that IPv6 should have addresses with different scopes? This architectural view means that some addresses will not be usable for e2e communications in the global Internet. They will only be usable in specific area, zones, sites (whatever label you want to hang on the limited portion of the Internet where they work). I'm continuing to view this discussion, and the call for consensus, in the architectural sense, not the specific implementation laid down by your 3 points. Is that your intent, or am I misinterpreting your consensus call?
Again, I fail to see how deprecating site-local addresses (specifically the FEC0::/10 prefix) solves the underlying problem (e2e communications failing with some src/dst address pairs).
Rich
At 02:02 PM 4/3/03 -0500, Margaret Wasserman wrote:
Hi Richard,
I have a real hard time understanding why proponents of the depreciate SL's claim that SL's would require special handling by applications , while unique PI's don't. If an address has limited scope, i.e., there is an address filter somewhere in the network that prohibits global e2e connectivity, then sometimes applications will fail to establish connections using those addresses.
The primary differences between IPv6 unicast site-local addresses (FECO::/10), as defined today, and PI addresses are:
1. Site-local addresses are intentionally ambiguous. 2. Sites may not overlap or be nested. 3. Sites need to be convex, constraining their boundaries to routing area or AS boundaries.
Most of the implementation complexity comes from #1 and, IMO, we would be much better off with an unambiguous form of local addressing. There are a few proposals for MAC-address based versions or unique IPv4-address based versions. We could also ask registries to provide globally unique provider-independent addresses for this purpose. Perhaps there are other choices. I am not actually a proponent of the "random choice" model, BTW.
#2 and #3 are constraints caused by forcing local addressing in to the model current defined for IPv6 scoped addressing. The scoping rules probably make sense for multicast addresses (that's what they were originally invented for), but I think that they place unnecessary constraints on local addresses.
Realistically, people will want to have overlapping and nested definitions of "local" access -- perhaps a marketing department with a special marketing printer, inside a company that has an internal corporate Internet site. You can't make this work with site-locals (no nesting), so you would already need a different mechanism for additional levels of access control... (filters and firewalls, I'd most likely). So, what do you gain from having one level of "local" defined by site-local addresses?
So I don't accept your point below that SL's require special handling by apps, but unique random addresses that provide the same function don't.
What am I missing that leads you to a different conclusion?
I think what you are missing is the impact of ambiguity. Site-local addresses require special handling because the same address may not point to the correct node (and may in fact point to the wrong node) when used outside of the originating contexts. Firewall/filter constrained globally unique addresses don't have this problem. You may not be able to reach them, but you will at least know that you were trying to reach the right node.
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] --------------------------------------------------------------------
------------------------------------
Richard A. Carlson e-mail: [EMAIL PROTECTED] Network Research Section phone: (630) 252-7289 Argonne National Laboratory fax: (630) 252-4021 9700 Cass Ave. S. Argonne, IL 60439
-------------------------------------------------------------------- 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] --------------------------------------------------------------------
