RE: draft-ietf-ipv6-ula-central-02.txt

["Templin, Fred L" <[e-mail]>]

 

> -----Original Message-----
> From: Scott Leibrand [mailto:[e-mail]] 
> Sent: Thursday, June 21, 2007 5:13 PM
> To: IETF IPv6 Mailing List
> Subject: Re: draft-ietf-ipv6-ula-central-02.txt
> 
> james woodyatt wrote:
> > On Jun 21, 2007, at 15:26, Templin, Fred L wrote:
> >>
> >> Maybe I am missing the point, but there seems to be an implication 
> >> that ULA-C necessarily implies IPv6 NAT; am I misinterpreting? If 
> >> not, then I don't quite understand why this implication is being 
> >> drawn. Can someone please explain?
> >
> No, ULA-C doesn't require NAT, any more than RFC 1918 or 
> ULA-L space does.

That matches my understanding, which leaves me sort of
wondering how NAT has crept into these discussions. 

> > I'm not going so far as to say the implication is there.  I'm just 
> > have a very difficult time taking seriously the concern about merge 
> > risks associated with renumbering due to the birthday paradox in a 
> > 2^40 number space without something more substantial to go 
> on than a 
> > bald-faced assertion that any small but non-zero probability of 
> > collision is unacceptable.
> 
> That assertion has been made, but I don't think we can treat it as 
> anything more than a preference by non-technical business people.

I have seen both sides of this street being played in other
working group contexts (sometimes even by the same people).
Some say: "probability of collision must be zero", and others
say: "birthday paradox says risk of collision is practically
nil". Wouldn't ULA-C satisfy both sides?

Fred
[e-mail]

> >   The alternative explanation that makes the most sense to 
> me is that 
> > some influential organizations, which are too small to 
> warrant their 
> > own PI space, are resisting migration to IPv6 unless they 
> can use NAT 
> > with private addresses, and they won't [or can't] explain why the 
> > arguments in RFC 4864 and 
> > draft-ietf-v6ops-scanning-implications-03.txt are failing 
> to persuade 
> > them.
> >
> Whether people end up using NAT or not, RFC 4864 specifically states 
> that "When changing ISPs or ISPs readjust their addressing 
> pool, DHCP-PD 
> [12] can be used as an almost zero-touch external mechanism 
> for prefix 
> change in conjunction with a ULA prefix for internal connection 
> stability."  This implies, as I have argued previously, that it is 
> appropriate in some cases, particularly the absence of PI 
> space, to use 
> a ULA prefix for numbering internal infrastructure like router 
> interfaces.  If I am a network operator doing so, I would like my 
> internal infrastructure addresses to have valid PTRs, which 
> requires DNS 
> delegation, which requires ULA-C.
> 
> To my mind, the main advantage of ULA-C over ULA-L is the ability to 
> register your space and delegate reverse DNS authority to the 
> appropriate name servers, such that anyone on your network or any 
> privately-connected network can resolve PTR requests for addresses in 
> your ULA block.
> 
> -Scott
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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