6to4 assigns a /48 IPv6 prefix (within 2002://16) to any host or site
with a global IPv4 address. The length of this prefix was chosen to be
the same as the size of a native prefix that was to be allocated to
sites, in order to ease coexistence of 6to4 and native IPv6 and/or
transition from 6to4 to native IPv6. If the normal site prefix
allocation had been /56 or some other value, we would have given serious
consideration to making 6to4 prefixes be the same length.
The document I cited in my previous note says (on this topic):
4.1. RFC3056: Connection of IPv6 Domains via IPv4 Clouds
RFC3056 [RFC 3056] describes a way of generating IPv6 addresses from
an existing public IPv4 address. That document describes an address
format in which the first 48 bits concatenate a well-known prefix
with a globally unique public IPv4 address. The "SLA ID" field is
assumed to be 16 bits, consistent with a 16-bit "subnet id" field. To
facilitate transitioning from an RFC3056 address numbering scheme to
one based on a prefix obtained from an ISP, an end site would be
advised to number out of the right most bits first, using the left
most bits only if the size of the site made that necessary.
Similar considerations apply to other documents that allow for a
subnet id of 16 bits, including [ULA-ADDRESSES].
6to4 is now widely deployed
Is it? Can you cite any data?
and ships with every major operating system. It's a bit late to
change the length of its prefix. But now sites that deploy 6to4
will have some disincentive to move to native IPv6 (or to delay
doing so) in that their pain in transition will be even greater than
before.
6to4 is a transition technique that I would argue is not really
appropriate for a large site (i.e, one with _many_ subnets). A large
site almost certainly will seek a more proper IPv6 connection to an
ISP. Yet, it is only large (multi-subnet) sites that will have
problems with having used all 16 bits for subnet addressing and then
moving to something with less. And if the site really was using 16
bits of subnet addressing, I expect their ISP would give it to them.
But again, I ask, just how widely deployed is it? The people I talk to
don't seem to think it is. I really don't think there is a problem
here in practice.
The /48 prefix length is not just some knob that RIRs or ISPs can turn
at their will. It's a constant that's embedded into 6to4 protocol
implementations in tens or hundreds of millions of computers.
Give me a break. Use leading zeros for the first 8 bits of the subnet
part and everything else still works just fine.
That doesn't mean that /48 can't be reexamined, but it does mean
that it's not the RIRs or ISPs business to be making that decision.
Um, Keith, it _is_ the RIR's business. This is what they do. They did
it for IPv4 and they are doing it for IPv6. If you have an issue with
this, you are at least 5 years too late.
I keep getting the impression that the biggest barrier to the success of
IPv6 is that so many people have screwed with the design of IPv4 that
they think they have the right to screw with IPv6 too.
The biggest barrier to the success of IPv6 is the lack of a short-term
ROI. There just isn't a strong business case for anyone to invest in
deployment. It's really that simple.
It continues to amaze me what rationals people can come up with for
why IPv6 hasn't been more widely deployed. We need just one more
transtion technique. RIRs need to give addresses away for free (oh,
wait, they've already tried that), etc., etc.
Bottom line: when the pain of IPv4 (with increasingly scarce/costly
addresses) and NAT exceeds the pain of deploying IPv6, we'll see
deployment.
Thomas
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf