Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr-03.txt

From: Dan Lanciani <[email-masked]>
Date: Fri, 9 Apr 2004 16:15:42 -0400 (EDT)

Kurt Erik Lindqvist <[email-masked]> wrote:

|> |=> At least you and I agree FWIW :)
|> |Perhaps I missed this discussion, but I can't see
|> |why they should be put in the global DNS.
|>
|> One might want to build an overlay network where consenting sites know 
|> how
|> to reach each other by constructing dynamic tunnels based on some (yet 
|> to
|> be defined) mapping function.  Thus the addresses may well be 
|> reachable in
|> some sense.
|
|But is this reason enough to have them in the global DNS tree.

Certainly.  If they are in the global DNS then the overlay network can be
handled entirely by routers (or even stub hosts) that know how to look up the
mapping and create the tunnels.  This is the approach I intend to use if unique
addresses become a reality.  If the addresses are not allowed in the global DNS
then multi-faced or multi-rooted DNS (or worse) hacks are required to allow
applications to see the addresses in the first place.

I strongly object to restricting unique addresses from the global DNS.  It
seriously compromises their utility and it does nothing to make anyone's
life easier.  Applications must already deal with the case of addresses that
are not reachable because of filters.  There is no reason to single these
addresses out for second-class treatment.

				Dan Lanciani
				ddl@danlan.*com

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 9 Apr 2004 17:37:57 -0700

I agree with Dan. Unless someone can show explicit harm to a third party by
putting them in the global DNS, there is no reason to even discuss their
presence or absence in the global DNS. 

Tony

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
> Lanciani
> Sent: Friday, April 09, 2004 1:16 PM
> To: [email-masked]
> Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-addr-
> 03.txt
>

---

From: Pekka Savola <[email-masked]>
Date: Sat, 10 Apr 2004 08:56:48 +0300 (EEST)

> presence or absence in the global DNS. 

I think there are two (operational -- can't be checked by the
implementation) cases here:

 1) putting in local addresses to global DNS names which are expected 
    to be used by outsiders who are not interested of local 
    addresses, or to whom local addresses could even mean a
    service degradation. (e.g., www.example.com, smtp.example.com, 
    etc.etc.)

 2) putting in local addresses for names which are not expected to be 
    used (e.g., "canada.vpn.example.com", to perform some kind of 
    "auto-discovery" functions) except who know which hostnames those 
    are and know what they're doing.

In the former, adding them makes very little sense.  In the latter,
adding them might be beneficial, while I'm not sure I can see the
scenario as I think one might want to use global addresses instead..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 12 Apr 2004 03:47:52 -0700

'Making sense' or not is not something that the IETF needs to specify in
MUST/SHOULD/MAY terms. There may be reasons to discuss the potential impact
of implementing that way, but that is the most the IETF should do. Again,
unless there is impact to a 3rd party, putting local use addresses in the
global DNS is none of the IETF's business.

Tony

> From: Pekka Savola [mailto:[email-masked]]
> Sent: Friday, April 09, 2004 10:57 PM
> To: Tony Hain
> Cc: 'Dan Lanciani'; [email-masked]
> Subject: RE: Response to AD comments on draft-ietf-ipv6-unique-local-addr-
> 03.txt
> 
> > > handled entirely by routers (or even stub hosts) that know how to look
> up
> > > the
> > > mapping and create the tunnels.  This is the approach I intend to use
> if
> > > unique
> > > life easier.  Applications must already deal with the case of
> addresses
> > > that

---

From: Pekka Savola <[email-masked]>
Date: Mon, 12 Apr 2004 16:15:10 +0300 (EEST)

On Mon, 12 Apr 2004, Tony Hain wrote:
> Again,

If you look at the case 1) below, that for certainty is a case which
would impact third parties.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 12 Apr 2004 19:44:02 +0200

>>>     are and know what they're doing.

You guys seem to be confusing two very different things:

a. putting these addresses in the forward DNS tree
b. putting these addresses in the reverse DNS tree

Now obviously a. can be harmful, but this is immaterial as anyone can 
do this today anyway.

I don't see how b. can be harmful in any way: only when someone has a 
reason to look up a certain addresses, she will see whether it's there 
or not. So as long as the addresses don't leak out, there is no 
problem. And if the addresses DO leak out, being able to look them up 
is a plus.

The only logical conclusion is that for registry assigned unique site 
local addresses, the registry MUST provide the registree with the 
option of registering reverse DNS servers.

As for randomly generated mostly-unique site locals... I think it would 
make sense to synthesize reverse DNS servers inside the address range 
in question here.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 12 Apr 2004 21:29:08 +0200

My main concern would be with actually _running_ the reverse three. If 
we are not talking about relaying on this for services and 
infrastructure - who do I call when it breaks?

- - kurtis -

On 2004-04-10, at 02.37, Tony Hain wrote:

>> handled entirely by routers (or even stub hosts) that know how to 
>> look up
>> the

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 14 Apr 2004 11:39:23 -0700

That is not a 3rd party scenario. The network manager is serving 2 sets of
customers. Therefore the network manager is required to keep the services to
those independent customer sets straight. If the 'outsider' (party 1) gets
back unusable addresses it is the network manager's (party 2) problem. There
is no 3rd party. It is worth noting that this might happen if the customers
are served from the same database, and network managers need to be aware of
what they put in the DNS servers for each customer set, but in no way does
it justify a MUST NOT. That is a local policy decision based on local needs.
It is not something the IETF gets to decide.

Tony 

> Sent: Monday, April 12, 2004 6:15 AM
> To: Tony Hain
> > > > I agree with Dan. Unless someone can show explicit harm to a third
> party
> > > by
> > > > > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> > > Dan
> > > > > Lanciani
> > > > > Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-
> local-
> > > addr-
> > > > > 03.txt
> > > > >
> > > > > |> One might want to build an overlay network where consenting
> sites
> > > know
> > > > > |> how
> > > > > |> to reach each other by constructing dynamic tunnels based on
> some
> > > (yet
> > > > > |> to
> > > > > Certainly.  If they are in the global DNS then the overlay network
> can
> > > be
> look
> > > > > addresses become a reality.  If the addresses are not allowed in
> the
> > > > > global DNS
> > > > > then multi-faced or multi-rooted DNS (or worse) hacks are required
> to
> > > > > allow
> > > > > I strongly object to restricting unique addresses from the global
> DNS.
> > > It
> > > > > are not reachable because of filters.  There is no reason to
> single
> > > these
> > > > > Administrative Requests:
> https://www1.ietf.org/mailman/listinfo/ipv6