Re: one example of an unintended consequence of changing the /48 boundary

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

 



> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]