Bob Hinden wrote:
Martin Rex wrote:
With a fully backwards compatible transparent addressing scheme,
a much larger fraction of the nodes would have switched to actively
use IPv6 many years ago.
Right, just like they could have deployed dual stack many years ago too.
Just two days
Martin,
Yes, the issues with an unconditional prefer IPv6 approach
have been noted, and operating systems of the vintages you
mention certainly deserved criticism. In fact this has been a
major focus of IPv6 operational discussions, and lies behind
things like the DNS whitelisting method, the
Yes, the issues with an unconditional prefer IPv6 approach
have been noted, and operating systems of the vintages you
mention certainly deserved criticism. In fact this has been a
major focus of IPv6 operational discussions, and lies behind
things like the DNS whitelisting method, the
On 02/23/2012 13:51, ned+i...@mauve.mrochek.com wrote:
Old news perhaps, but an unavoidable consequence of this is that the
oft-repeated assertions that various systems have been IPv6 ready for over 10
years don't involve a useful definition of the term ready.
The OP specified IPv4 only
On 02/23/2012 13:51, ned+i...@mauve.mrochek.com wrote:
Old news perhaps, but an unavoidable consequence of this is that the
oft-repeated assertions that various systems have been IPv6 ready for over
10
years don't involve a useful definition of the term ready.
The OP specified IPv4
On 02/23/2012 14:48, Ned Freed wrote:
On 02/23/2012 13:51, ned+i...@mauve.mrochek.com wrote:
Old news perhaps, but an unavoidable consequence of this is that the
oft-repeated assertions that various systems have been IPv6 ready for over
10
years don't involve a useful definition of the term
On 02/23/2012 14:48, Ned Freed wrote:
On 02/23/2012 13:51, ned+i...@mauve.mrochek.com wrote:
Old news perhaps, but an unavoidable consequence of this is that the
oft-repeated assertions that various systems have been IPv6 ready for
over 10
years don't involve a useful definition of the
In message 01occ10b11tc00z...@mauve.mrochek.com, ned+i...@mauve.mrochek.com w
rites:
On 02/23/2012 14:48, Ned Freed wrote:
On 02/23/2012 13:51, ned+i...@mauve.mrochek.com wrote:
Old news perhaps, but an unavoidable consequence of this is that the
oft-repeated assertions that various
In message 01occ10b11tc00z...@mauve.mrochek.com, ned+i...@mauve.mrochek.com
w
rites:
On 02/23/2012 14:48, Ned Freed wrote:
On 02/23/2012 13:51, ned+i...@mauve.mrochek.com wrote:
Old news perhaps, but an unavoidable consequence of this is that the
oft-repeated assertions that
Mark Andrews wrote:
Brian already covered unconditional prefer-IPv6 was a painful lesson
learned, and I'm not saying that those older systems did it right.
You learned a wrong lesson, then.
The essential problem is that there is half hearted support
for handling multiple addresses.
It is not
On 2012-02-24 12:32, ned+i...@mauve.mrochek.com wrote:
In message 01occ10b11tc00z...@mauve.mrochek.com,
ned+i...@mauve.mrochek.com w
rites:
...
I contend that OS are IPv6 ready to exactly the same extent as they
are IPv4 ready. This isn't a IPv6 readiness issue. It is a
*application*
ned+i...@mauve.mrochek.com wrote:
This definition of ready is operationally meaningless in many cases.
The meaningful question is whether we have to modify code or not.
If we have to, a host is not ready. And, if it is not an
implementation problem, protocols must be fixed.
If we don't have
In message 201202231651.q1ngpxgl017...@fs4113.wdf.sap.corp, Martin Rex writes
:
Bob Hinden wrote:
Martin Rex wrote:
With a fully backwards compatible transparent addressing scheme,
a much larger fraction of the nodes would have switched to actively
use IPv6 many years ago.
Bob Hinden wrote:
ID/locator split, which I've been
a proponent of for very many years, works a lot better with more bits,
because it allows topological addressing both within and outside an
organization.
To confirm what your are saying about an ID/locator split in
IPv6, that the other
On 2/16/2012 6:46 PM, Steven Bellovin wrote:
Why? Apart from the fact that if this transition is painful, the next
one will be well-nigh impossible, having more bits lets us find creative
ways to use the address space.
Not to single out Steve, but my recollection is that that view was at
Steve,
On Feb 16, 2012, at 6:46 PM, Steven Bellovin wrote:
On Feb 16, 2012, at 8:30 39PM, Masataka Ohta wrote:
Steven Bellovin wrote:
Thus, IPv6 was mortally wounded from the beginning.
The history is vastly more complex than that. However, this particular
decision
was just about
From: Bob Hinden bob.hin...@gmail.com
the other reason why we went with 128-bit address with a 64/64 split
as the common case and defining IIDs that indicate if they have
global uniqueness. This creates a framework that an ID/locator split
could be implemented. ... we
Noel,
On Feb 17, 2012, at 10:32 AM, Noel Chiappa wrote:
From: Bob Hinden bob.hin...@gmail.com
the other reason why we went with 128-bit address with a 64/64 split
as the common case and defining IIDs that indicate if they have
global uniqueness. This creates a framework that an ID/locator
On 2012-02-18 08:10, Bob Hinden wrote:
Noel,
On Feb 17, 2012, at 10:32 AM, Noel Chiappa wrote:
From: Bob Hinden bob.hin...@gmail.com
the other reason why we went with 128-bit address with a 64/64 split
as the common case and defining IIDs that indicate if they have
global uniqueness.
Steven Bellovin wrote:
Thus, IPv6 was mortally wounded from the beginning.
The history is vastly more complex than that. However, this particular
decision
was just about the last one the IPng directorate made before reporting back to
the IETF -- virtually everything else in the basic
On Feb 16, 2012, at 8:30 39PM, Masataka Ohta wrote:
Steven Bellovin wrote:
Thus, IPv6 was mortally wounded from the beginning.
The history is vastly more complex than that. However, this particular
decision
was just about the last one the IPng directorate made before reporting back
G'day.
Always fun to watch an exchange among entrenched perspectives...
On 2/14/2012 9:31 AM, Bob Braden wrote:
However, Vint Cerf, the ARPA program manager, rules against variable length
addresses and decreed the fixed length 32 bit word-aligned addresses of RFC
791. His argument was that
From: Bob Braden bra...@isi.edu
You probably remember this, but...
I was on the very edge at the time (more below), but yes. A few things that
caught my eye (including a minor date offset - I like to get noise out of the
record before it gets engrained):
argued strenuously for
On Wed, 2012-02-15 at 13:23 -0500, Noel Chiappa wrote:
The sad part is that we could have had our cake, and eaten it too!
If a (hierarchical) variable length addressing would not have mandated a
hierarchical routing as well, then yeah, cake would have tasted well as
it remained there on the
On 15-Feb-12 08:42, Dave CROCKER wrote:
As I recall, there was essentially no experience with variable length
addresses -- and certainly no production experience -- then or even by
the early 90s, when essentially the same decision was made and for
essentially the same reason.[1]
It's not
On 2/15/2012 1:10 PM, Stephen Sprunk wrote:
The problem with variable-length addressing that, in practice, one needs
to specify a maximum length.
In some practical terms, perhaps, but there are extensibility schemes that allow
the payload (addressing bits, in this case, to go on forever, in
This is essentially correct. The apparent conceptual difference is that a
variable length address looks more like source routing. The end system owns
only a small part of the total address; the rest is the network portion,
fashioned to seem like a source route. Depending on how the address
The problem with variable-length addressing that, in practice, one needs
to specify a maximum length.
In some practical terms, perhaps, but there are extensibility schemes that
allow the payload (addressing bits, in this case, to go on forever, in
theoretical terms.
I look forward to
The problem with variable-length addressing that, in practice, one needs
to specify a maximum length.
In some practical terms, perhaps, but there are extensibility schemes that
allow
the payload (addressing bits, in this case, to go on forever, in theoretical
terms.
One example would be
On 2/15/2012 1:39 PM, Richard Barnes wrote:
The problem with variable-length addressing that, in practice, one needs
to specify a maximum length.
In some practical terms, perhaps, but there are extensibility schemes that
allow the payload (addressing bits, in this case, to go on forever, in
From: Steve Crocker st...@shinkuro.com
a variable length address looks more like source routing.
...
the network portion, fashioned to seem like a source route.
... the division of the network portion into routing steps will be
specified in advance or will be
Scott, if memory serves you and I wanted the high-order 2 bits of the IPng
address to select between 64, 128, 192, and 256-bit addresses -- and when
we couldn't get that we got folks to agree on 128-bit addresses instead of
64-bit, which is what had been on the table.
On Feb 14, 2012, at 1:37
: Wednesday, February 15, 2012 4:10 PM
To: ietf@ietf.org
Subject: Re: Variable length internet addresses in TCP/IP: history
On 15-Feb-12 08:42, Dave CROCKER wrote:
As I recall, there was essentially no experience with variable length
addresses -- and certainly no production experience -- then or even
On Feb 15, 2012, at 5:44 53PM, Ross Callon wrote:
But the maximum for implementation is not necessarily the maximum for the
packet format.
Thus one could have started with a variable length address format, but said
For the immediate future we will always pick a length of 32 bits. Then
Steve Crocker wrote:
The only way variable length address would have provided a
smooth transition is if there had been room to increase the
length of the address after some years of use.
Bottom up approach to extend address length toward port numbers,
thus, worked, is working and will keep
Steven Bellovin wrote:
Scott, if memory serves you and I wanted the high-order 2 bits of the IPng
address to select between 64, 128, 192, and 256-bit addresses -- and when
we couldn't get that we got folks to agree on 128-bit addresses instead of
64-bit, which is what had been on the table.
On Feb 15, 2012, at 7:43 30PM, Masataka Ohta wrote:
Steven Bellovin wrote:
Scott, if memory serves you and I wanted the high-order 2 bits of the IPng
address to select between 64, 128, 192, and 256-bit addresses -- and when
we couldn't get that we got folks to agree on 128-bit addresses
On 2/13/2012 7:53 PM, Noel Chiappa wrote:
From: Brian E Carpenterbrian.e.carpen...@gmail.com
The design error was made in the late 1970s, when Louis Pouzin's advice
that catenet addresses should be variable length, with a format prefix,
was not taken during the
The word alignment issue was very strong and the router people had considerably
more influence than the host folks. I tried to propose variable length
addressing using four bit nibbles in August 1974 and I got no traction at all.
Steve
Sent from my iPhone
On Feb 14, 2012, at 6:31 PM, Bob
in the case of IPng, the router people wanted variable length but the host people (or at least some of them) did not
Scott
Scott O Bradner
Senior TechnologyConsultant
Harvard University Information Technology
Innovation Architecture
(P) 1 (617) 495 3864
29 Oxford St. Rm 407
Cambridge,
Bob Braden wrote:
Within the ARPA-funded Internet research program that designed IP and
TCP, Jon Postel and Danny Cohen argued strenuously for variable length
addresses. (This must have been around 1979. I cannot name most of the
other 10 people in the room, but I have a clear mental
Martin,
One the one hand, the IETF was frowning upon NATs when they were
developed outside of the IETF. But if you look at the IETFs
(lack of) migration plan, the translation that you need in order
to make old-IPv4 interoperate with new-IPv6, is actually worse than
an IPv4 NAT.
I'm sorry,
Brian E Carpenter wrote:
Martin,
One the one hand, the IETF was frowning upon NATs when they were
developed outside of the IETF. But if you look at the IETFs
(lack of) migration plan, the translation that you need in order
to make old-IPv4 interoperate with new-IPv6, is actually
In message 201202142245.q1emjaou019...@fs4113.wdf.sap.corp, Martin Rex writes
:
The necessary changes to applications would be minimal,
the happy eyeballs contortion completely unnecessary
and the security assessment for an IPv6 enabled network
*MUCH* simpler.
Happy eyeballs just points out
Martin,
On Feb 14, 2012, at 2:45 PM, Martin Rex wrote:
Brian E Carpenter wrote:
Martin,
One the one hand, the IETF was frowning upon NATs when they were
developed outside of the IETF. But if you look at the IETFs
(lack of) migration plan, the translation that you need in order
to make
Brian E Carpenter wrote:
I'm sorry, but *any* coexistence between RFC791-IPv4-only hosts and
hosts that are numbered out of an address space greater than 32 bits
requires some form of address sharing,
Sure.
address mapping, and translation.
Not at all.
Realm Specific IP [RFC3102] is such
Mark Andrews wrote:
Happy eyeballs just points out problems with multi-homing in general.
IPv4 has the *same* problem and sites spend 1000's of dollars working
around the issue which could have been addressed with a couple of
extra lines of code on the client side in most cases.
It's Brian
The deployment problem was not due to technical issues, it was because
the Internet changed to only deploy new technology that generated
revenue in the short term. After a lot of thought, I have come to the
conclusion that it wouldn't have mattered what the IETF did, we would
still be facing
On 2012-02-15 11:45, Martin Rex wrote:
Brian E Carpenter wrote:
Martin,
One the one hand, the IETF was frowning upon NATs when they were
developed outside of the IETF. But if you look at the IETFs
(lack of) migration plan, the translation that you need in order
to make old-IPv4
Why? They would have needed updated stacks. The routers would
have need updated stacks. The servers would have needed updated
stacks. The firewalls would have needed updated stacks. The load
balancers would have needed updated stacks. Many MIBs would have
needed to be updated. DHCP servers
On Feb 14, 2012 7:40 PM, Randy Bush ra...@psg.com wrote:
Why? They would have needed updated stacks. The routers would
have need updated stacks. The servers would have needed updated
stacks. The firewalls would have needed updated stacks. The load
balancers would have needed updated
Brian E Carpenter wrote:
With a fully backwards compatible transparent addressing scheme,
a much larger fraction of the nodes would have switched to actively
use IPv6 many years ago.
Why? They would have needed updated stacks. The routers would
have need updated stacks. The servers would
On Feb 15, 2012, at 1:56 AM, Bob Hinden wrote:
Martin,
On Feb 14, 2012, at 2:45 PM, Martin Rex wrote:
Brian E Carpenter wrote:
Martin,
One the one hand, the IETF was frowning upon NATs when they were
developed outside of the IETF. But if you look at the IETFs
(lack of) migration
53 matches
Mail list logo
