RE: IPv6 transition architecture discussion

["Jeroen Massar" <jeroen@unfix.org>]

Joshua Graessley wrote:

> On Sunday, November 24, 2002, at 08:46 PM, Bound, Jim wrote:
> 
> >> -----Original Message-----
> >> From: Pekka Savola [mailto:pekkas@netcore.fi]
> >> Hello,

<SNIP>

> The vocal people in this working group say that 6to4 and 
> Teredo are bad solutions. They rightly point out that the few 6to4 
> relays will probably melt down or people will stop running them. In 
> addition, there is no such thing as a Teredo relay deployed today. 
> Teredo and 6to4 work well when there are many relays, which 
> is not the case today.

My opinion is certainly NOT that it is a _bad_ solution au contrair.
But you did want are to use it for the wrong thing.


> We look to the IETF for a solution because we can't solve 
> this problem 
> alone. I get the impression from this working group that the working 
> group is of the opinion that the transition mechanism will 
> not work and we should just sit on our thumbs until the ISPs provide
us IPv6 
> connectivity.

This is the right approach indeed. Discussing this with multiple
vendors and people who have experience in deployment already does
help find out what is going on.

IMHO for IPv6 to get a big push at this moment one needs two things:
 1) Application support.
 2) ISP support.

Application support is being worked on, many programmers change their
current IPv4-only applications to support IPv6 simply by using
getaddrinfo().

ISP support should be pushed by RIPE/ARIN/APNIC.
The APNIC and RIPE regions are working quite hard. Taking a look
at the ARIN region though makes me worry a bit.

> >> A starter for discussion: v6 connectivity is very poor (see
> >> draft-savola-v6ops-6bone-mess-01 for more).  Vendors are
> >> rightfully afraid (I sure don't want them doing it) to enable
> >> v6 by default, as connections could easily switch to using
> >> (badly working) v6.

6bone-mess is named 6bone mess as it's the mess of the 6bone.
The 6bone will fade away. RIR space will be left.
There are talks under a group of ISP's to clean up the RIR/6bone

> > What vendor told you they are afraid?  If you cannot state 
> who that is
> > then please retract this statement.
> 
> We are concerned, I'm not sure I'd say afraid. We have 
> shipped Mac OS X 
> 10.2, with support for IPv6. It isn't really well integrated yet, but 
> it's there. It will assign link-local addresses, listen for routing 
> advertisements, and assign addresses. This is fine because almost no 
> one has IPv6 connectivity. We were considering turning on 6to4 by 
> default when there are no routing advertisements. This working group 
> has dissuaded us from doing so. If we did turn on 6to4, we would want 
> to add some extra smarts to getaddrinfo to list IPv4 addresses first 
> when 6to4 is in use to reduce the load on the relays.

Pekka mentioned a certain thing (prefer IPv4 over IPv6 dns queries).
This would lessen the use of IPv6 where it could be used IMHO.

Another approach to this is to test for IPv6 connectivity every N
times a month* or something like that and turn on the above feature.

*= ping6/connect to a certain host on the internet which is well
connected.
Eg "testforipv6.apple.com" :)

> If we didn't modify getaddrinfos behavior, websites that used to work,
may 
> not work if the relays are down, or it may be very inefficient to
communicate 
> with such hosts since 6to4 could send the tunneled packets to a relay 
> just about anywhere.
> 
> Based on feedback in this working group and some feedback at the
recent 
> IETF in Atlanta, we will probably not be working to get IPv6 
> connectivity on all Mac OS X hosts.
> 
> > All vendors shipping products have web pages and kits to 
> install IPv6.
> > You might go buy them and test them for yourself.  Also all our
> > interoperability labs are doing this now UNH, ETSI, TAHI, and now 
> > China.
> > This is none of the IETFs businss or v6ops unless that 
> works points to 
> > a
> > protocol or operations problem on the network.  If you know of such
> > cases I am sure the chairs would love to hear them.
> 
> Why are these optional kits to install IPv6? If vendors really felt 
> comfortable about IPv6, they would ship support built in to 
> the product 
> and it would be enabled by default. The fact is, very few people have 
> IPv6 connectivity. IPv6 connectivity is the exception, not the rule.
> 
> >> Do we need to do something about this or just wait N years to
> >> operators to do something.  Note: this is a chicken-and-egg
> >> problem, ISP's don't deploy v6 before it's requested (and
> >> paid for, in some way or another), and the connectivity
> >> remains poor because v6 isn't really production yet.
> >
> > ISPs are deploying IPv6 you simply don't know what your 
> talking about.
> > Right now it is in test bed mode and that will last awhile 
> and it has
> > nothing to do with anything we can do in the IETF to help at this 
> > point.
> > The one thing we could do is stop wasting mail messages 
> with mail like
> > this and get some decisions made about SLs, Scenarios, et 
> al.   That is
> > the IETF's job not this diatribe you spew out here all to 
> often, that 
> > is
> > totally irrelevant to the building of standards.
> 
> Is there any evidence to suggest that IPv6 will some day make 
> the move 
> from testbed to wide deployment? The IETF has a huge amount 
> to do with 
> how quickly IPv6 moves from testbed to deployment. The IETF 
> has drafts 
> defining transition strategies. These transition strategies are 
> important. Without them, IPv6 will never move on from test bed 
> deployment. If people continue to ignore the transition problem and 
> insult those who bring it up, perhaps IPv6 will go the way of OSI.
> 
> <SNIP>
> 
> >> x) there are probably many other "really important" issues we
> >> need to have
> >> some idea of.  It's not all that useful to meddle with
> >> scenario details
> >> until we have some idea how the big picture should work itself out.
> >
> > What your asking is the kind of discussions one has when building
> > products.  But I don't agree and the chairs have made it 
> pretty clear 
> > we
> > must work on scenarios.  I have come to support that and it 
> makes some
> > logical sense.   The scenarios are about use cases and 
> people deploying
> > now and that is the big picture.
> 
> <sarcasm>Yes, scenarios are more important since people participating 
> in the IETF will be building scenarios instead of products. 
> After all, 
> it doesn't matter that a something be implemented in a 
> product so long 
> as there's a scenario in which the protocol could be used.</sarcasm>
> 
> >> I think this is something we need to properly discuss now and
> >> possibly at
> >> the next meeting.
> >
> > I simply disagree and strongly do not support this and ask the
chairs to
> > kill 90% of what you suggest as out of scope for this mail list and
the
> > IETF.
> 
> Perhaps it is too early to be folding the ng-trans working group 
> efforts in to v6-ops?

Maybe in the US, but not in Europe and Asia! :)


Greets,
 Jeroen