> > In a nutshell, the point you are trying to make is that RFC1918
> > addresses are bad because NAT exists.
>
> no, that's missing the point. use of RFC 1918 addresses in a network
> that can also use global Internet addresses is harmful regardless of
> whether that connection to the global Internet uses NAT or whether it
> is merely via a router that filters traffic to/from the 1918 addresses.
>
> NAT is irrelevant to this particular problem. The problem is that
> in the presence of either 1918 or SLs applications have to deal with
> a mixture of scoped and global addresses without any good way of knowing
> whether such an address is valid (and whether it means the same thing)
> in the context of a particular node.
Which just means that we need to provide a way for the application /
library to return appropriate addresses. Make SL work rather than
saying "kill them" or "don't put them in the DNS".
I've already said how to put them in the DNS. It requires a new
record but it will work and it will remove the need for two faced
DNS unless the sites *wants* to use two faced DNS to hide the records.
Site locals provide a solution for a certian problem space. They
do create additional problems but they are not insolvable problems
and are no different to the problems causes by LLs.
You need a function that looks up names and returns addresses along
with the scope_id. We have that in getaddrinfo(). You need a
function that takes a address and a scope_id and returns the name.
We don't have that but it is very easy to do that in the DNS if you
want to privided you have a scope-id to scope-name function which
is need.
e.g.
<reverse-nibble>.<scope-name> PTR <name>
It's not zero-conf but sites will most probably never be zero-conf.
e.g.
foo.example.net. SA6 1080:0:0:0:8:800:200C:417A .
foo.example.net. SA6 FE80:0:0:0:8:800:200C:417A my-site.example.net.
foo.example.net. SA6 FEC0:0:0:0:8:800:200C:417A my-link.example.net.
c.0.0.2.0.0.8.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.0.1.ip6.arpa. (
PTR foo.example.net. )
c.0.0.2.0.0.8.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.my-site.example.net. (
PTR foo.example.net. )
c.0.0.2.0.0.8.0.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.C.E.F.my-link.example.net. (
PTR foo.example.net. )
and you have a local table that maps
my-site.example.net and my-link.example.net to appropiate scope-id
values.
Now if you want to send address between applications in binary format
just send SA6 rdata instead of AAAA rdata.
Applications / libraries can filter out the addresses that are
not useful to them if they want.
Mark
> > 2. site-local is bad because RFC1918 is bad.
>
> sorry - the two are quite similar, and they cause similar problems for apps.
>
> > >> and a global address.
> >
> > > please, elaborate. I haven't seen a good one yet.
> >
> > A somehow isolated subnet, where most hosts would have site-local only
> > addresses, except for a gateway or proxy that would have both.
>
> that's what 1918 was intended for. again, I don't have a huge problem
> with it as long as the apps don't have to deal with multiple scopes -
> but experience with 1918 predicts that that's exactly what will happen.
>
> > > you're missing the burden that having a mixture of SLs
> > > and globals puts on apps.
> >
> > You are missing the point, IMHO. This is not your call nor mine.
> > Site-local addresses do exist, been there for long, some people will
> > purposedly choose to use them in combination with global addresses. As
> > of today, the address selection draft addresses use of site-local and
> > global addresses simultaneously and I do not see a reason to change it.
>
> IETF's job is to try to explain what will make the network work well.
> Imposing constraints on the use of SLs will help the network work better.
> If SLs are encouraged as in the current draft it will degrade the ability
> of the network to support applications.
>
> 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]
> --------------------------------------------------------------------
--
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]
--------------------------------------------------------------------
