Subject: v4 side unmodifiable

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 6 Dec 2007 17:31:54 -0800

Jari basically said this ^^

However, although I agree it's true in the general case, I think for  
non-trivial servers/services, this isn't true: if there is a good  
reason to make changes on the IPv4-only side, it may be possible to  
make them.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 06 Dec 2007 18:39:28 -0800

I don't think is a good idea to modify IPv4. It is the same difficulty than
having IPv6 in those boxes where the manufacturers aren't longer in the
market, they have no spare memory, or whatever.

And I believe is not good to make a difference between what is a server and
a client from this perspective. May be need to look into concrete examples,
but it is looking already for a solution too early ?

We should really focus in trying to make it in the hosts that are have an
IPv6 stack.

Regards,
Jordi

> De: Iljitsch van Beijnum <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Thu, 6 Dec 2007 17:31:54 -0800
> Para: IPv6 Operations <[email-masked]>
> Asunto: v4 side unmodifiable
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 06 Dec 2007 20:12:55 -0800

> but it is looking already for a solution too early ?
I think that, in order to ensure we find the solutions which can be 
deployed (easily, quickly, cheaply, etc.),
we need to identify three things:
- what can be done (on an element-by-element basis)
- what the required elements of a specific solution involve
- what the specific corner cases are in the problem space.

Here is an example of the problem space having a corner case:
If a content provider (who operates farms of servers, where the servers 
are commodity, new, and open source),
wants to provide content to IPv6-only sites, there is a real problem.

Even if the provider has IPv6 transit and a dual-stack infrastructure, 
there is a problem.

If the provider adds AAAA records, it can trigger a bad user experience 
from unintended sources (e.g. toredo hosts).
These are not within the control of the content provider. The content 
provider is limited to solutions within its control.

So, that provider may actually *want* to have solutions from our 
solution space as options, and is likely willing to make
changes on the v4 *server* host to accomplish this.

It is an exception, of course, but a very important one for 
consideration, as the uptake of IPv6 depends on content being available, 
at no worse a quality of user experience as under IPv4 (for the same sites).

Brian Dickson

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 07 Dec 2007 09:36:08 -0800

My experience on this is that if the content provider setup its own Teredo
and 6to4 relays, then users will have no troubles.

So again, no need to modify the IPv4 stack on that service provider network.

Of course, there will be ALWAYS users with problems, but this is the corner
case due to missconfiguration of the users network. For example, the network
adminstrator decides to announce an IPv6 prefix with RA or DHCPv6, but has
no IPv6 connectivity to outside. Then the hosts in that network will not try
6to4 or Teredo (because they believe they have already native IPv6
connectivity), and will fail. This kind of situations are unavoidable and
not due to IPv6 or anything that we do, is just a problem of BAD networks
administrators, not doing correctly their job :-( Same can happen with a bad
IPv4 network configuration, even if IPv6 is not involved !

Regards,
Jordi

> De: Brian Dickson <[email-masked]>
> Fecha: Thu, 06 Dec 2007 20:12:55 -0800
> Para: <[email-masked]>
> CC: "[email-masked]" <[email-masked]>
> Asunto: Re: v4 side unmodifiable
> 

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 7 Dec 2007 20:06:29 +0200

> from unintended sources (e.g. toredo hosts).

I am fairly disturbed when even IETF IPv6 experts fail to recognize that this 
(a Teredo or 6to4 host trying to connect to a native dual-stack host) does 
not happen, and is hence not an issue. Why do you think Source Address 
selection was invented for?

As it happens, I am not aware of any vendor with 6to4 and/or Teredo 
on-by-default *without* proper Source Address Selection policy. As such, if 
you do put a "native" AAAA record in addition to an existing A record, only 
native IPv6 host will (try to) use IPv6 to connect to you.

Indeed, from my personal experience as a "I eat my dog food" guy, there are 
many more problems establishing native-native IPv6 connections, than when 
using automated transition mechanism. That is not to say that transition 
mechanisms are reliable (which they are not). But the fact is that there are 
still a awful lot of (native) IPv6 routing issues, and that's one thing 
Source Address Selection cannot and does not protect against.

-- 
Rémi Denis-Courmont

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 7 Dec 2007 20:14:03 +0200

> reason to make changes on the IPv4-only side, it may be possible to

That would depend on your definition of "non-trivial". But I am afraid Jari is 
right - host still lacking an IPv6 stack are either not upgradeable, or not 
willing to be upgraded.

As someone pointed out already, modifying even existing IPv6-capable host is 
pretty difficult: it would be 15 years or so before the Windows more recent 
than Vista would have a fair share of the market, if it ever happens.

Also worth considering is the self-realizing prophecy factor - if >80% of 
IETFers think that a given IETF technology (say modifying IPv4 stacks to 
support IPv6 transition) won't happen, how likely is it to be successful 
anyway? :(

-- 
Rémi Denis-Courmont

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 07 Dec 2007 10:21:40 -0800

Yes, but software may decide not to use the source address selection policy
of the OS. For example, if I recall correctly, Opera uses IPv6 even with
Teredo to connect to IPv6 sites, while IE follows the policy table and
prefers to use IPv4 if only Teredo is available.

Regards,
Jordi

> De: Rémi Denis-Courmont <[email-masked]>
> Organización: Remlab.net
> Fecha: Fri, 7 Dec 2007 20:06:29 +0200
> Para: "[email-masked]" <[email-masked]>

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

---

From: "Suresh Krishnan" <[email-masked]>
Date: Fri, 7 Dec 2007 14:25:39 -0500

Hi Iljitsch,
  I think I have the same opinion as Jari for two reasons

* Any node that does not have a v6 implementation today
  probably does not want one. So any v4 based changes will
  not be delployed
* Why would a v4 host that has no pain currently try to change
  itself to talk to a v6 host (who has the pain). The pain should
  be where the gain is.

Cheers
Suresh

> De: Iljitsch van Beijnum <[email-masked]> Responder a: 
> <[email-masked]>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 7 Dec 2007 17:10:33 -0800

> right - host still lacking an IPv6 stack are either not upgradeable,  

The case I'm thinking about is a service that is somewhere up there in  
the top 10000 destinations on the web. That's big enough to make  
deploying IPv6 non-trivial (especially now that Vista boxes enable  
6to4 when they have a public address even if protocol 41 is filtered  
so they can't reach destinations with a AAAA record) but the operators  
of such a service would presumably be willing to install reasonable  
updates if that buys them something useful.

I think we really should start considering a transition phase where  
the clients may run IPv6 but the servers largely don't. (I know, home  
users can also run servers, peer-to-peer, all that good crap.)

> than Vista would have a fair share of the market, if it ever happens.

Hm, pre-XP windows is quickly disappearing and both XP and Vista  
should be considered updatable if Microsoft chooses to do so. So in  
another few years the main class of unupgradable IPv4 hosts will be  
special purpose devices rather than computers running a general  
purpose operating system. But obviously updatable in principle doesn't  
mean it will happen on 100% of all boxes.

> Also worth considering is the self-realizing prophecy factor - if  
> >80% of

After wednesday's plenary? Highly likely.  :-)

Note that I wasn't talking about upgrading ALL IPv4 hosts, I was just  
saying that SOME classes of IPv4 hosts can very likely be upgraded.

---

From: Bob Hinden <[email-masked]>
Date: Sat, 8 Dec 2007 11:10:14 -0800

Iljitsch,

> However, although I agree it's true in the general case, I think  
> for non-trivial servers/services, this isn't true: if there is a  
> good reason to make changes on the IPv4-only side, it may be  
> possible to make them.

To clarify, I think it should be "the IPv4 stack in an IPv4 only host  
is unmodifiable".  I would would think that small modifications to  
the IPv4 side of a dual stack host is possible and have likely  
happened already.  This would be inline with your observation about  
dual stack servers.

Bob

---

From: Christian Huitema <[email-masked]>
Date: Sat, 8 Dec 2007 12:51:23 -0800

> the top 10000 destinations on the web.

Why are we worried about that? The top 10000 destinations are typically located in big server farms, with a rich set of equipment. If there appears to be a sizeable IPv6 development, these 10000 top sites will become someone's business opportunity. There may be some form of conversion going on, but most likely it will be located somewhere in the server farm, e.g. some upgraded version of the current load balancers and firewalls.

-- Christian Huitema

---

From: Mohacsi Janos <[email-masked]>
Date: Sun, 9 Dec 2007 21:53:43 +0100 (CET)

> prefers to use IPv4 if only Teredo is available.

This behavior would indicate very bad coding practice in Opera....
I will test it....

Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

---

From: Fred Baker <[email-masked]>
Date: Sun, 9 Dec 2007 13:33:08 -0800

>   itself to talk to a v6 host (who has the pain). The pain should

yes...

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 09 Dec 2007 23:08:03 +0100

I don't completely agree. If certain applications decide to use Teredo if
native neither 6to4 is not available, because they prefer IPv6 even if
performance may seem lower, avoiding implementing a NAT traversal, because
it is actually about the same as using Teredo, I don't think is a bad coding
practice. Is it just a developer decision to use or not the default OS
policy table. This is also the reason this table can be modified ! But you
many need to avoid modifying it because that will affect all the
applications.

Regards,
Jordi

> De: Mohacsi Janos <[email-masked]>
> Fecha: Sun, 9 Dec 2007 21:53:43 +0100 (CET)
> Para: JORDI PALET MARTINEZ <[email-masked]>

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Dec 2007 11:12:59 +1300

On 2007-12-10 10:33, Fred Baker wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 

I think you really have to look carefully at the incentives.
If you're running services in order to make money, and a
significant population of IPv6-only clients appears, you
will be strongly incented to support them. So yes, the
pain should be where the gain is, but that could well be
on the IPv4 side. (I believe that argues for dual stack
services, however, not for fiddling with the legacy stack.)

     Brian

---

From: Remi Denis-Courmont <[email-masked]>
Date: Mon, 10 Dec 2007 13:22:55 +0100

On Sun, 09 Dec 2007 23:08:03 +0100, JORDI PALET MARTINEZ

> performance may seem lower, avoiding implementing a NAT traversal,

because

> it is actually about the same as using Teredo, I don't think is a bad

> coding practice.

You could _perhaps_ hold that case for a ***peer-to-peer*** application.

Opera is a Web browser. There is no such things as "NAT traversal" problems

when it comes to HTTP (because HTTP is _the_ most basic benchmark for a NAT

device).

Any HTTP client that ignores the policy table in any way, such as

by forcefully trying IPv6 before IPv4, is just plain BROKEN.

Same thing for POP, IMAP, SMTP, IRC (let alone DCC),

FTP with EPSV, XMPP or any other client-server TCP-based protocol.

-- 

Rémi

---

From: Mohacsi Janos <[email-masked]>
Date: Mon, 10 Dec 2007 18:15:23 +0100 (CET)

> FTP with EPSV, XMPP or any other client-server TCP-based protocol.

Agreed. The other group could be monitoring or diagnostic tools that 
directly using IPv6 or IPv4 without policy table....

Best Regards,
  		Janos

---

From: Francis Dupont <[email-masked]>
Date: Mon, 10 Dec 2007 18:24:40 +0100

I proposed the RFC 3484 policy table to be per application: a default
system wide table with the possibility to put in the environment of
an application / user / etc (i.e., everything one can associate with
an environment) a policy table and address selection control flag.
 This should give both the flexibility to apply a special policy in
some cases, for instance use the local care-of address for printers
than the remote home address, and the control over what policy is used.

Regards

[email-masked]