Re: EUI-48 globally unique site-locals (GUSL)
Aidan, For each link, a router may automatically assign a site-local address from an EUI-48 (ie a MAC address) using the following address format: | 12 bits | 48 bits | 4 bits | 64 bits| +-+--+--+--+ | fef | router device ID | sub ID | machine interface ID | +-+--+--+--+ Figure 1: Address Format: fef0::/12 BTW, two bits in an EUI-48 (i.e., the g and u bits) are not needed if using this as a global token, so it could be easily compressed to 46 bits leaving two more bits for the subnet. I am not sure this helps very much with the other problems raised. Bob 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: unique enough [RE: globally unique site local addresses]
1. Local, private addresses that do not communicate outside of their site. Site-locals are perfect for this, if they are not limited to disconnected sites. 2. Unique addresses that do not need public Internet access but do need to communicate with selected external sites (example customer/supplier VPN). This is GUPI. 3. Global network layer PI identifiers. Although this is not directly linked to the multihoming issue, it is likely that a scalable multihoming solution would provide it. I do not envision a large-scale deployment of IPv6 without providing all three. Also, it would be a hell of a good idea if 2. could migrate to 3. why doesn't #1 suffice for #2? 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: globally unique site local addresses
Margaret Wasserman wrote: Hi Andrew, 4 or 6 subnet bits are not sufficient for most uses. It is expected that these addresses will be used for internal numbering within an enterprise, so we should, at minimum, leave room for a 16-bit subnet ID. This would allow the same subnet numbers to be used for global and local subnets. The key point of my proposal must be unclear. I'm not proposing leaving 4 or 6 bits to number the site. Instead, I'm proposing that each router number the subnets it is attached to - ie subnet identifiers are automatically generated from a 50+ bit space. A draft has been written and is working its way through a review process. Hopefully that will make things clearer. -- Andrew White[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]
Re: unique enough [RE: globally unique site local addresses]
1. Local, private addresses that do not communicate outside of their site. Site-locals are perfect for this, if they are not limited to disconnected sites. 2. Unique addresses that do not need public Internet access but do need to communicate with selected external sites (example customer/supplier VPN). T his is GUPI. 3. Global network layer PI identifiers. Although this is not directly linke d to the multihoming issue, it is likely that a scalable multihoming solution would provide it. I do not envision a large-scale deployment of IPv6 without providing all three. Also, it would be a hell of a good idea if 2. could migrate to 3. why doesn't #1 suffice for #2? Keith are you sure you ment this? #2 works for #1 not the other way around. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [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]
Re: unique enough [RE: globally unique site local addresses]
why doesn't #1 suffice for #2? Keith are you sure you ment this? #2 works for #1 not the other way around. right you are. I transposed them. Keith 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: unique enough [RE: globally unique site local addresses]
Keith, Michel Py wrote: 1. Local, private addresses that do not communicate outside of their site. Site-locals are perfect for this, if they are not limited to disconnected sites. 2. Unique addresses that do not need public Internet access but do need to communicate with selected external sites (example customer/supplier VPN). This is GUPI. 3. Global network layer PI identifiers. Although this is not directly linked to the multihoming issue, it is likely that a scalable multihoming solution would provide it. Keith Moore wrote: why doesn't #2 suffice for #1? [I transposed it back the way you meant] Because #2 does not exist today. You must provide #2 before you try to kill #1. Network administrators do not design production networks with promises. Michel. 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: unique enough [RE: globally unique site local addresses]
why doesn't #2 suffice for #1? [I transposed it back the way you meant] Because #2 does not exist today. You must provide #2 before you try to kill #1. well, then I strongly recommend that we do that. Keith 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]
