Re: My Questions on Site-Locals
Julian, I think the one problem we need to avoid is What do you do when two occurrences of FEC0::0001/64 exist within a single routing domain? This is the problem created by the current SL definition when two 'sites' are united by merger or VPN and they both happen to have a subnet #1. We shot ourselves in the foot by creating this problem in the initial IPv6 addressing architecture. Brian Sellers, Julian P wrote: Keith's multi-party applications won't work if the parties refer non-global addresses to each other. Margaret recommends that everyone use global addresses, but filter certain prefixes at various administrative boundaries. How, then, do Keith's applications know which addresses have global scope and which do not? A tacit assumption seems to be that applications will not have to deal with link-local addresses. I'm aware of the recommendation not to place link-local addresses in the DNS, but I know of no prohibition of applications communicating via link-local addresses. If they may do so, is this less problematic than using site-local addresses? Since I know nothing about filtering in routers, can someone tell me why filtering on FEC0::/10 is more complex than filtering on prefixes chosen by the local administrator(s)? And concerning Margaret's point on nesting sites, could routers not filter within FEC0:0:subn:etid::/64 addresses? Again citing the disclaimer re my lack of knowledge, the filtering-on-locally-designated-prefixes method seems unwieldy compared to the filtering-on-well-known-scope method. Implementations can allow an administrator to configure address scope preferences using the well-known scopes. Nodes (applications) on the same subnet could then have addresses of different scopes. This would be cumbersome at best without well-known scopes. Some have complained about the complexity of always disambiguating site-local addresses by means of their zone identifiers. This seems insignificant to me; the same must be done for link-local addresses. The zone identifier accompanies the address wherever it goes. Right? I understand that sites that merge would have to renumber if their subnet IDs conflicted. Some have stated that a disconnected site using site-local addresses must renumber when it connects to the Internet. Wouldn't the site simply add the new prefix(es), and the nodes use the new addresses and/or site-local addresses based on local configuration? Connections using site-local addresses would not be affected by connection to the Internet. Since so many wise people object to site-local addressing, the problems must be greater than they appear from behind these cube walls. But I have not seen answers to these questions (or maybe I failed to comprehend). I look forward to having my horizons expanded. Julian Sellers Enterprise Server Communications Engineering Unisys Corporation 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]
Re: My Questions on Site-Locals
Brian, Am Freitag, 4. April 2003 15:14 schrieb Brian E Carpenter: What do you do when two occurrences of FEC0::0001/64 exist within a single routing domain? This is the problem created by the current SL definition when two 'sites' are united by merger or VPN and they both happen to have a subnet #1. We shot ourselves in the foot by creating this problem in the initial IPv6 addressing architecture. Do we really have to think about this? Is this an architectural design problem? Is it enough to drop the whole concept? I think it would be enough to come up with a BCP how to subdivide bits 11-48 in an intelligent way to prevent above. There were lots of ideas how this could be done on this list. Christian 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]
Re: My Questions on Site-Locals
Christian Schild (JOIN Project Team) wrote: Brian, Am Freitag, 4. April 2003 15:14 schrieb Brian E Carpenter: What do you do when two occurrences of FEC0::0001/64 exist within a single routing domain? This is the problem created by the current SL definition when two 'sites' are united by merger or VPN and they both happen to have a subnet #1. We shot ourselves in the foot by creating this problem in the initial IPv6 addressing architecture. Do we really have to think about this? Is this an architectural design problem? Is it enough to drop the whole concept? The architecture today specifies ambiguous subnet prefixes. I think it would be enough to come up with a BCP how to subdivide bits 11-48 in an intelligent way to prevent above. There were lots of ideas how this could be done on this list. But that is not what the addressing architecture describes today, and that is where my problem is, not with some future specification. Brian 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]
Re: My Questions on Site-Locals
Hi Christian, At 03:53 PM 4/4/2003 +0200, Christian Schild (JOIN Project Team) wrote: I think it would be enough to come up with a BCP how to subdivide bits 11-48 in an intelligent way to prevent above. There were lots of ideas how this could be done on this list. We do need to define some method(s) to produce unique, local, provider-independent addresses (i.e. MAC address-based or registry-based). But, I don't think that we want those local addresses to have the semantics associated with site-local addressing, so I don't think that we should allocate them from the current site-local space (FECO::/10). Most of the restrictions and complexities associated with scoped addresses in the scoped addressing architecture (can't be nested, can't overlap, need zone IDs to disambiguate, etc.) are required _because_ site local addresses are ambiguous. If you remove the ambiguity, why would you want to live with the restrictions? Let's deprecate the current site-local prefix, and define a non-ambiguous model for local addressing. Unique local addresses can, generally, be treated just like any other addresses. As long as we make sure that our method of creating uniqueness retains the property that a longest prefix match will result in using local address to reach local addresses and global address to reach global addresses, we shouldn't need any special handling for these addresses in hosts or routers. 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]
