On 2007-10-12 16:27, Jun-ichiro itojun Hagino wrote:
On 2007-10-11 23:46, Jun-ichiro itojun Hagino wrote:
Not viewed from the socket programmer's point of view.
Look at how an AF_INET6 socket behaves when given
an address like :::192.0.2.3
afaik the behavior is then exactly what you
The IPv4 clock will wind down right after the last FORTRAN compiler is
decomissioned.
actually it looks like FORTRAN is going to outlast IPv4 by several years.
Wouldn't it make more sense to put the effort into morphing v6 into
something that *IS* attractive?
perhaps, though there's precious
From: Keith Moore [EMAIL PROTECTED]
Wouldn't it make more sense to put the effort into morphing v6 into
something that *IS* attractive?
there's precious little time left to do that
Umm, Keith, we're *already* 'out' (in some sense) of IPv4 space, and have
been for a decade or
Noel Chiappa wrote:
From: Keith Moore [EMAIL PROTECTED]
Wouldn't it make more sense to put the effort into morphing v6 into
something that *IS* attractive?
there's precious little time left to do that
Umm, Keith, we're *already* 'out' (in some sense) of IPv4 space, and
The IPv4 clock will wind down right after the last FORTRAN compiler is
decomissioned. Wouldn't it make more sense to put the effort into
morphing v6 into something that *IS* attractive?
hope you can do that in time... (i mean, not just for the States
but for the entire
Not viewed from the socket programmer's point of view.
Look at how an AF_INET6 socket behaves when given
an address like :::192.0.2.3
afaik the behavior is then exactly what you describe.
Whether the stacks are independent code modules or
alternate paths through the same code is
From: [EMAIL PROTECTED] (Jun-ichiro itojun Hagino)
Cc: ietf@ietf.org
Not viewed from the socket programmer's point of view.
Look at how an AF_INET6 socket behaves when given
an address like :::192.0.2.3
afaik the behavior is then exactly what you describe.
Whether the stacks are
Brian E Carpenter wrote:
No more than having your TCP use selective acks constitutes a 'dual
stack', relative to having TCP not use selective acks. While what I
suggested isn't that minor an enhancement to the stack, neither does it
constitute an entirely separate stack.
To repeat: Dual
The underlying point of my note was:
One would think that a 15-year project that was pursued to solve a
fundamental Internet limitation but has achieved such poor adoption
and use
would motivate some worrying about having made some poor decisions. A
quick response that says we talked
Dave,
Reordering your comments slightly.,..
--On Thursday, 11 October, 2007 11:07 -0400 Dave Crocker
[EMAIL PROTECTED] wrote:
To repeat: At some point, it would help to take history as
being instructive, rather than to dismiss attempts at
considering alternatives.
This might not change
Dave,
On 2007-10-12 04:07, Dave Crocker wrote:
...
The underlying point of my note was:
One would think that a 15-year project that was pursued to solve a
fundamental Internet limitation but has achieved such poor adoption
and use
would motivate some worrying about having made some poor
On 2007-10-11 23:46, Jun-ichiro itojun Hagino wrote:
Not viewed from the socket programmer's point of view.
Look at how an AF_INET6 socket behaves when given
an address like :::192.0.2.3
afaik the behavior is then exactly what you describe.
Whether the stacks are independent code modules or
Dave Crocker [EMAIL PROTECTED] writes:
4. The v6 stack would need to have a v4 mode, for use by v4
applications -- applications that use v4 addresses.
Um, sounds an awful lot like dual-stack to me. Hosts (that understand
IPv6) also must be able to originate and receive either IPv4 packets
To repeat: Dual stack is entirely separate.
That's the approach that was chosen. IPv6 is an incompatible protocol
module, compared with IPv4. Independent addressing. Independent
interfacing. Independent management.
What I described was a compatible upgrade. Very different beast.
Brian - is it provable that no design for a follow-on to IPv4 would
have provided that backward compatibility? Or were there
architectural and engineering decisions that chose other features
over backward compatibility?
And, I guess I'll stop here as I'm rehashing a train that long ago
Brian - OK, I agree that a wide range of tunneling/translation
mechanisms have been considered; was the transition problem
considered during the basic design?
In any event, in my opinion we don't have a fundamental level of
backward compatibility that would solve the current deployment
On Oct 9, 2007, at 8:49 AM, Ralph Droms wrote:
is it provable that no design for a follow-on to IPv4 would have
provided that backward compatibility?
Hi Ralph,
I don't know about 'provable', but there's a strong argument as to
why that's challenging.
Any new design would have
On Oct 9, 2007, at 9:43 AM, Tony Li wrote:
Any new design would have necessarily required more bits to address
more end systems. Making legacy systems interact with these
additional addressing bits without some form of gateway, NAT or
other translation would indeed be challenging. You're
On Oct 9, 2007, at 11:29 AM, David Conrad wrote:
On Oct 9, 2007, at 9:43 AM, Tony Li wrote:
Any new design would have necessarily required more bits to
address more end systems. Making legacy systems interact with
these additional addressing bits without some form of gateway, NAT
or
Ralph Droms wrote:
Brian - is it provable that no design for a follow-on to IPv4 would have
provided that backward compatibility? Or were there architectural and
engineering decisions that chose other features over backward
compatibility?
1. Take the original, simple Deering
Thus spake Tony Li [EMAIL PROTECTED]
On Oct 9, 2007, at 11:29 AM, David Conrad wrote:
On Oct 9, 2007, at 9:43 AM, Tony Li wrote:
Any new design would have necessarily required more bits to address
more end systems. Making legacy systems interact
with these additional addressing bits without
Brian - is it provable that no design for a follow-on to IPv4 would
have provided that backward compatibility? Or were there
architectural and engineering decisions that chose other features
over backward compatibility?
1. Take the original, simple Deering specification.
2.
On 2007-10-10 12:44, Keith Moore wrote:
Brian - is it provable that no design for a follow-on to IPv4 would
have provided that backward compatibility? Or were there
architectural and engineering decisions that chose other features
over backward compatibility?
1. Take the original, simple
Stephen,
Perhaps, if the folks hadn't been so dogmatically against NAT at the
time, the v4-to-v6 transition model would have worked similarly and we'd
be done with it by now...
I doubt it. The underlying problem with NAT doesn't go away whatever you
do. IMHO, there probably isn't any true
On 2007-10-05 09:12, Ralph Droms wrote:
Typo: should read IPv6 ~= IPv4+more_bits...
- Ralph
On Oct 4, 2007, at Oct 4, 2007,4:52 AM, Ralph Droms wrote:
Regarding transition:
On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote:
Unless I've missed something rather basic, in the
Regarding transition:
On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote:
Unless I've missed something rather basic, in the case of IPv6,
very little
attention was paid to facilitating transition by maximizing
interoperability
with the IPv4 installed base.
Dave, I have to agree
Typo: should read IPv6 ~= IPv4+more_bits...
- Ralph
On Oct 4, 2007, at Oct 4, 2007,4:52 AM, Ralph Droms wrote:
Regarding transition:
On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote:
Unless I've missed something rather basic, in the case of IPv6,
very little
attention was
Are there any documents that give adoption instructions for
what are expected to be common scenarios? These would be
step-by-step cookbooks, with explanations for when they apply
and when they don't?
There are lots and lots of documents in lots and lots of places. Many of
them were
David Conrad wrote:
Tony,
On Sep 13, 2007, at 5:29 PM, Tony Hain wrote:
David Conrad wrote:
IPv6 _is_ IPv4 with more bits and it is being deployed that way.
No it is not, and you need to stop claiming that because it
confuses people
into limiting their thinking to the legacy
Tony Hain wrote:
The fact that people -can- deploy IPv6 the same way they deploy IPv4
is a feature, not a requirement that they actually deploy it that way.
Statements like yours only confuse people because they take it literally
rather than in context that current deployments are not
On 14 Sep 2007 at 09:38 -0400, Thomas Narten allegedly wrote:
David Conrad [EMAIL PROTECTED] writes:
As I have said elsewhere, I've come to believe that one of the
fundamental failures of the IETF is that it permits or even
encourages protocol design to be directed by corner cases.
But
I'm not particularly interested in getting into a Yes it is!
No it isn't! debate. I will merely point out that IPv6 has
been implemented and is being deployed as IPv4 with more
bits.
If more people would get involved in developing a best practices
document for IPv6, perhaps through a
I wonder if even
writing a BCP about this even makes sense at this point,
because the application writers (or authors of the references
the application writers use) may never see the draft, or even
be concerned that it's something they should check for.
I think that it does make sense
On 14-sep-2007, at 22:34, Greg Skinner wrote:
When routing connectivity could be restored quickly, the maintained
state
at both ends of the TCP connection would allow the application to
proceed normally. However, this practice doesn't seem to have made it
into the application-writing
On 14-sep-2007, at 5:34, Keith Moore wrote:
What we'd really need is a
RR type specifically intended to map service names onto instance
ID+address pairs, and also a special query type that wasn't defined to
return all of the matching RR records, but would instead return a
random
subset or a
On Thu, Sep 13, 2007 at 05:29:39PM -0700, Tony Hain wrote:
David Conrad wrote:
IPv6 _is_ IPv4 with more bits and it is being deployed that way.
No it is not, and you need to stop claiming that because it confuses people
into limiting their thinking to the legacy IPv4 deployment
What we'd really need is a RR type specifically intended to map
service names onto instance ID+address pairs, and also a special
query type that wasn't defined to return all of the matching RR
records, but would instead return a random subset or a subset based
on heuristics, and finally
given that NATs violate the most fundamental assumption
behind IP (that an address means the same thing everywhere in
the network), it's hardly surprising that they break TCP.
Has RFC 2526 been deprecated?
-- Michael Dillon
P.S. RFC 2526 - Reserved IPv6 Subnet Anycast Addresses
David Conrad [EMAIL PROTECTED] writes:
Do you believe IPv4 (or ANY other successful large scale technology),
when it was designed, had all the little details worked out?
No, of course not. But the analogy is misleading, IMO. When IPv4 was
designed, it was used by a _very_ small set of
Dave,
On Sep 13, 2007, at 5:43 PM, Dave Crocker wrote:
David Conrad wrote:
IPv6 _is_ IPv4 with more bits and it is being deployed that way.
That sort of equivalence statement applies when the new version is
a minor upgrade to the previous, rather than require massive
changes to the
On Sep 13, 2007, at 6:01 PM, Fred Baker wrote:
What would be Really Nice would be to in some way ensure that
applications never saw IP addresses at all - they *only* worked on
names, and maintained no knowledge in the application of what
address was used.
I always thought an opportunity
Bill,
On Sep 14, 2007, at 2:15 AM, Bill Manning wrote:
On Thu, Sep 13, 2007 at 05:29:39PM -0700, Tony Hain wrote:
IPv6 _is_ IPv4 with more bits and it is being deployed that way.
beating this dead horse...
The official IETF state sport.
actually, David is profoundly wrong.
Frequently.
David,
David Conrad wrote:
That sort of equivalence statement applies when the new version is a
minor upgrade to the previous, rather than require massive changes to
the infrastructure AND to client applications. Having to run parallel
stacks, having substantial changes to administration and
On Fri, Sep 14, 2007 at 07:48:45AM -0400, Keith Moore wrote:
[sorry, lost attribution here]
TCP protects you from lots of stuff, but it doesn't really let you
recover from the remote endpoint rebooting, for example...
well, duh. if the endpoint fails then all of the application-level
From: Greg Skinner [EMAIL PROTECTED]
It seemed like a reasonable thing to do to treat something like a net
or host unreachable as a transient condition ...
However, this practice doesn't seem to have made it into the
application-writing community at large, because lots of
David,
We had an opportunity to fix that, but we blew it.
I think everyone agrees that having that flexibility
(ease of renumbering, no routing explosion in the
core etc) would be good.
But I would suggest that instead of playing the
what if or I told you so games, we collectively
focus on
Jari,
On Sep 13, 2007, at 1:05 PM, Jari Arkko wrote:
We had an opportunity to fix that, but we blew it.
I think everyone agrees that having that flexibility
(ease of renumbering, no routing explosion in the
core etc) would be good.
So would world peace, motherhood, and apple pie. What are
On Thu, Sep 13, 2007 at 11:05:22PM +0300, Jari Arkko wrote:
David,
We had an opportunity to fix that, but we blew it.
I think everyone agrees that having that flexibility
(ease of renumbering, no routing explosion in the
core etc) would be good.
But I would suggest that instead of
David Conrad wrote:
IPv6 _is_ IPv4 with more bits and it is being deployed that way.
Probably not really.
That sort of equivalence statement applies when the new version is a minor
upgrade to the previous, rather than require massive changes to the
infrastructure AND to client
From: Tony Hain [EMAIL PROTECTED]
David Conrad wrote:
IPv6 _is_ IPv4 with more bits and it is being deployed that way.
No it is not,
No less a person than the IPv6 'architect' himself stated that IPv6 and
IPv4 were architecturally identical, that IPv4 got it all basically
David Conrad wrote:
IPv6 _is_ IPv4 with more bits and it is being deployed that way.
No it is not, and you need to stop claiming that because it confuses people
into limiting their thinking to the legacy IPv4 deployment model.
One
can argue that it shouldn't be that way and that
On Sep 14, 2007, at 2:22 AM, David Conrad wrote:
And I would suggest by ignoring history we are doomed to repeat
it. I am not engaging in I told you so because I didn't --
you'll note I used we. I am merely pointing out that we're
either at or very quickly approaching a crossroads and
Tony Hain wrote:
Until people get their heads out of the IPv4 darkness they will keep
insisting on making IPv6 deployments look the same.
Perhaps, but there's such a thing as IPv6 darkness also. For instance,
the assumption that existing applications can survive changes in the IP
addresses
Noel Chiappa wrote:
From: Tony Hain [EMAIL PROTECTED]
David Conrad wrote:
IPv6 _is_ IPv4 with more bits and it is being deployed that way.
No it is not,
No less a person than the IPv6 'architect' himself stated that IPv6 and
IPv4 were architecturally identical, that
Fred Baker wrote:
What would be Really Nice would be to in some way ensure that
applications never saw IP addresses at all - they *only* worked on
names, and maintained no knowledge in the application of what address
was used. To my small mind, forcing a new DNS lookup in the event of a
TCP
On Sep 14, 2007, at 6:03 AM, Keith Moore wrote:
perhaps, but it won't work reliably as long as there can be more
than one host associated with a DNS name, nor will it work as long
as DNS name-to-address mapping is used to distribute load over a
set of hosts.
well, this presumes that the
Fred Baker wrote:
What would be Really Nice would be to in some way ensure that
applications never saw IP addresses at all - they *only* worked on
names, and maintained no knowledge in the application of what address
was used. To my small mind, forcing a new DNS lookup in the event of a
To my small mind, forcing a new DNS lookup in the event of a
TCP session failure and restart would be a good thing.
perhaps, but it won't work reliably as long as there can be more than
one host associated with a DNS name, nor will it work as long as DNS
name-to-address mapping is
Have you ever used the term layer violation, or heard it used by
someone else?
Occasionally :)
Having the application know the network layer address is just slightly
worse than having it know what it's Ethernet address is or what port
it is attached to.
The flip side to this is that an
To my small mind, forcing a new DNS lookup in the event of a
TCP session failure and restart would be a good thing.
perhaps, but it won't work reliably as long as there can be more than
one host associated with a DNS name, nor will it work as long as DNS
name-to-address
I also don't have a lot of faith in should be, not when I've seen DHCP
servers routinely refuse to renew leases after very short times, nor
when I've heard people say that a site should be able to renumber every
day.
So, someone misconfigured something. Such misconfigurations
61 matches
Mail list logo
