[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-08.txt



>  > It costs real money to absorb the load.
> 
> Well understood. But it will be a while before this goes mainstream.

	The point is that we really will want to legitimise what
	as112 will have to do.  To tell the users of these addresses
	that they SHOULD / MUST configure their nameservers to cover
	atleast the ULA addresses they can route to (not only their
	own addresses).  To tell ISP's that they can configure their
	caching servers to respond to any queries that leak from
	their clients.  To tell those that don't use ULA's that they
	can configure their servers to answer these queries and that
	they won't cause problems.

	To tell users of ULA's that it is safe for them to setup
	their own versions of C.F.IP6.ARPA and D.F.IP6.ARPA.

	To make it legitimate for nameserver vendors to pre-configure
	there servers to block these zones with appropriate knobs
	to turn them off.

 	Mark

>     Brian
> 
> Mark Andrews wrote:
> >>Mark,
> >>
> >>I don't think "wait and see" is a cop-out, actually. Since these
> >>addresses are by definition useless on the Internet in general,
> >>I think local pragmatic decision taking is the best way to find
> >>out what we *should* recommend. It's not obvious to me that
> >>a typical corporate deployment of ULAs will need any reverse
> >>lookup at all. It may simply be a non-problem (apart from the load
> >>problem that as112 addresses as I understand it).
> >>
> >>     Brian
> > 
> > 
> > 	It's not a question of how many sites will populate the reverse
> > 	zones.  It's a question of how many sites will *not* setup the
> > 	reverse zone and how many applications will make a reverse
> > 	lookup on these addresses.
> > 
> > 	You are arguing above that most sites won't setup the reverse
> > 	zone.  This is the situation where you need the preconfigured
> > 	reverse zones the most.
> > 
> > 	It costs real money to absorb the load.  Money for servers.
> > 	Money for bandwidth to the servers.
> > 
> > 
> >>Mark Andrews wrote:
> >>
> >>>>Mark,
> >>>>
> >>>>At 03:16 PM 11/29/2004, Mark Andrews wrote:
> >>>>
> >>>>
> >>>>
> >>>>>       Section 4.4 DNS Issues
> >>>>>
> >>>>>       This sections appears to be a real cop out.
> >>>>>
> >>>>>       It is perfectly natural for clients to want to make queries and
> >>>>>       have these addresses returned from the DNS.
> >>>>
> >>>>There is a wide range of views on what is appropriate for putting these 
> >>>>addresses in the global DNS.  For now, I think the best way to move this 
> >>>>document forward is to leave it as is and wait until we have operational 
> >>>>experience.  Once there is some operational experience it would be good i
> f 
> >>>>V6OPS or DNSOPS wrote a document about the best way to do it.
> >>>>
> >>>>Bob
> >>>
> >>> 
> >>>	I think there is plenty of IPv4 experience that translates to
> >>>	this area.  This is basically saying that the as112 should be
> >>>	the default treatment for these reverse zones.
>>>
> >>>	See http://www.as112.net/
> >>>
> >>>--
> >>>Mark Andrews, ISC
> >>>1 Seymour St., Dundas Valley, NSW 2117, Australia
> >>>PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@xxxxxxx
> >>>
> >>>--------------------------------------------------------------------
> >>>IETF IPv6 working group mailing list
> >>>ipv6@xxxxxxxx
> >>>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> >>>--------------------------------------------------------------------
> >>>
> > 
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@xxxxxxx
> > 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@xxxxxxx

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@xxxxxxxx
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------