This is an effect of the current shortage of IPv4 addresses that IPv6 is supposed to address. Remember that the Internet was doing just fine before RFC1918 as well.
I disagree with this assessment. In the v4 world sites that are, voluntarily or forcibly, using RFC 1918 address do expect to connect into the public Internet. They do so because these are the only IP addresses they have, so what other choice do they have?
I don't think anyone here disagrees with what you are saying. However, what you are describing is the way that RFC1918 have been (ab)used. The argument is over the effects of using site-locals/RFC1918 addresses. That people would use site-locals in the same way as they use RFC1918 addresses today I don't think anyone questions.
The multi-address space in the v6 world is being presented in a different light. SLs are NOT replacements for RFC 1918 private addresses, they are just another option that a site can use if it chooses to. SLs have no meaning outside the site boundary, just as LLs have no meaning outside the local link and Globals have no meaning outside the global v6 Internet. Therefore it is not possible for 2 disjoint sites to connect to each other.
Agreed. Creating PI space will leave to growth of the routing table, which is a multi6-wg concern, and will also in a way destroy the aggregation intent with IPv6. It would however make site-locals more or less unnecessary.
The options to solve this should include getting globals or creating a new super-site that encompasses the individual sites. The pressure to deploy NATs will only come if we fail to provide these alternatives.
Allowing site-locals will have people use them the same way as they use RFC1918 space and that will lead to problems with deploying new applications built on peer-to-peer.
I think the peer-to-peer principle is more important than the routing-table growth. The routing-table will grow anyway, so we need to address that problem as it is.
- kurtis -
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
