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.
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.
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
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
