Overall I believe there is general agreement that this type of address is an improvement over site-local because the prefixes are unique.
Below is my summary of conclusions reached and open issues raised on the mailing list.
1) A global-ID of 41 bits is a reasonable choice.
2) It is important to allow for /48 prefixes (with 16-bit subnet IDs) to maintain compatibility with RFC3177.
3) The central allocation proposed in the draft is OK for some situations, but there is also need for local allocation for sites who can not want to use a central allocation authority. Pseudo-random numbers is a reasonable choice for this given the field size.. The suggestion made on the list to split FC00::/7 into FC00::/8 and FD00::/8 to allow for each type of allocations is a good approach.
I plan to make this change in the next version of the draft and include pseudo-code of an local allocation algorithm. Brain Haberman is helping with this text.
4) The scope of these address is smaller from global unicast address but larger than site-local. They are scoped in a different manner than link-local, site-local, and global in that the scope of an individual /48 prefix is created by a set of adhoc routing agreements and is not limited by the non-uniqueness of the prefix like site-local.
From a host's perspective this difference in scope shows up by different reachability than global unicast and could be handled by default that way. It is probably better for nodes and applications to treat them differently from global unicast addresses. A starting point might be to give them preference over global unicast, but fall back to global unicast if a particular destination is found to be unreachable. Much of this behavior can be controlled by how they are allocated to nodes and put into the DNS. However it is useful if a host can have both types of addresses and use them appropriately. This creates a host with multiple global addresses, a form of multihoming.
Approaches to this problem have been proposed in drafts like <draft-de-launois-multi6-naros-00.txt> where a server is queried for the best source and destination address pair to reach a destination. In the long term this approach might be combined with a DNS request where the request included all of the requesters source addresses that could be used and the resolver would return the preferred source and destination addresses. This is, of course, not a trivial change to DNS but might be a reasonable approach to move forward in this area.
I would proposed that the IPv6 w.g. define the address format and default node and application behavior, and leave the more ambitious address selection solutions to multi6 or other working groups as appropriate.
I would appreciate your feedback and thoughts.
Thanks, 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] --------------------------------------------------------------------
