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 > -----Original Message----- > From: Pekka Savola [mailto:[EMAIL PROTECTED] > Sent: Monday, April 12, 2004 6:15 AM > To: Tony Hain > Cc: 'Dan Lanciani'; [EMAIL PROTECTED] > Subject: RE: Response to AD comments on draft-ietf-ipv6-unique-local-addr- > 03.txt > > 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. > > > > -----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 --------------------------------------------------------------------
