Pekka Savola <[EMAIL PROTECTED]> wrote:

|On Mon, 12 Apr 2004, Tony Hain wrote:
|> Again,
|> unless there is impact to a 3rd party, putting local use addresses in the
|> global DNS is none of the IETF's business.
|
|If you look at the case 1) below, that for certainty is a case which
|would impact third parties.

People who are accessing your names in your DNS are not third parties; they
are first parties (or maybe second parties :).

Note that discussion of a "global DNS" tends to imply that there is some other
kind, indirectly endorsing multi-face and such.  Prohibiting addresses from
a "global DNS" virtually requires the use of multi-face.  Do we really want
to go there?  I'm not one who wants to prohibit multi-face DNS for those who
want it, but I don't want to be forced to use it myself...

                                Dan Lanciani
                                [EMAIL PROTECTED]

|> > -----Original Message-----
|> > From: Pekka Savola [mailto:[EMAIL PROTECTED]
|> > Sent: Friday, April 09, 2004 10:57 PM
|> > To: Tony Hain
|> > Cc: 'Dan Lanciani'; [EMAIL PROTECTED]
|> > Subject: RE: Response to AD comments on draft-ietf-ipv6-unique-local-addr-
|> > 03.txt
|> > 
|> > On Fri, 9 Apr 2004, Tony Hain wrote:
|> > > 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.
|> > 
|> > 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..
|> > 
|> > > > -----Original Message-----
|> > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
|> > Dan
|> > > > Lanciani
|> > > > Sent: Friday, April 09, 2004 1:16 PM
|> > > > To: [EMAIL PROTECTED]
|> > > > Subject: Re: Response to AD comments on draft-ietf-ipv6-unique-local-
|> > addr-
|> > > > 03.txt
|> > > >
|> > > > Kurt Erik Lindqvist <[EMAIL PROTECTED]> 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
|> > > >                                [EMAIL PROTECTED]
|> > > >
|> > > > --------------------------------------------------------------------
|> > > > IETF IPv6 working group mailing list
|> > > > [EMAIL PROTECTED]
|> > > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
|> > > > --------------------------------------------------------------------
|> > >
|> > >
|> > > --------------------------------------------------------------------
|> > > IETF IPv6 working group mailing list
|> > > [EMAIL PROTECTED]
|> > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
|> > > --------------------------------------------------------------------
|> > >
|> > 
|> > --
|> > Pekka Savola                 "You each name yourselves king, yet the
|> > Netcore Oy                    kingdom bleeds."
|> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
|> 
|> 
|> --------------------------------------------------------------------
|> IETF IPv6 working group mailing list
|> [EMAIL PROTECTED]
|> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
|> --------------------------------------------------------------------
|> 
|
|-- 
|Pekka Savola                 "You each name yourselves king, yet the
|Netcore Oy                    kingdom bleeds."
|Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
|
|
|--------------------------------------------------------------------
|IETF IPv6 working group mailing list
|[EMAIL PROTECTED]
|Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
|--------------------------------------------------------------------
|

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

Reply via email to