ietf
[Top] [All Lists]

Re: IPv10.

2016-11-11 21:00:47
On 12 November 2016 at 12:43, Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
On 12/11/2016 14:15, Randy Bush wrote:
Right now it seems that you have got a solution proposal
for a problem, that is IMHO not very clearly described.

how about ipv4 and ipv6 are incompatible on the wire and this
has created a multi-decade ipv6 charlie foxtrot?

Yes, I suggest mentioning that to Vint, Bob and a few others in 1977,
so that they can design IPv4 with extensible addresses. People in
2016 will be grateful.


It looks like the first version of TCP from 1974 had them.

"SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM"
https://tools.ietf.org/rfc/rfc675.txt

"4 bits: Length of destination network address in 4 bit units (current
   value is 1)

   4 bits: Destination network address

      1010-1111 are addresses of ARPANET, UCL, CYCLADES, NPL, CADC, and
      EPSS respectively.

 ...

   4 bits: length of source network address in 4 bit units (current
   value is 1)

   4 bits: source network address (as for destination address)"

or up to 60 bit addresses.

From what I've read, there were proposals to do variable length
addresses in IPv6 as CLNS did, however there was a concern that it
would be harder to cope with them in hardware, and the observation
that even though CLNS supported them, everybody just used the same
length.

More recently, I've heard of few organisations here in .au that have
run out of RFC1918s because they've been using /24s everywhere -
previously I only knew of Comcast running out for their cable modem
management network. I've also seen /24s universally being
"unnecessarily" used in virtual networks used to build virtual server
stacks.

It seems most people will choose simple and consistent when they can
even though it is less efficient. There's operational value in that -
if all subnets are /24s or /64s, then one with an incorrect length
sticks out like a sore thumb. Less variables means less opportunity
for error and errors being far more obvious.

Regards,
Mark.

<Prev in Thread] Current Thread [Next in Thread>