Mark, Because we could not clearly define sin6_scope_ID its basically a void in the base API now. And IEEE did the same thing. Works for link-locals yes. So if your DNS 2-face reqs that it won't work yet because of lack of consensus on scoping and no one has implemented a product for production networks today that use SLs. I asked Richard to speak up but until I hear from him I will assume that.
/jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:Mark.Andrews@;isc.org] > Sent: Monday, October 28, 2002 7:20 PM > To: Keith Moore > Cc: Michel Py; Margaret Wasserman; [EMAIL PROTECTED] > Subject: Re: Limiting the Use of Site-Local > > > > > > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
