> -----Original Message----- > From: Scott Leibrand [mailto:[EMAIL PROTECTED] > 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 [EMAIL PROTECTED] > > 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 > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
