WG Action: Conclusion of IP Version 6 (ipv6)

Mailman List Mirror (Read Only)
1

Date: Thu, 27 Sep 2007 11:57:07 -1000
From: Randy Bush <randy@psg.com>
Sender: owner-nanog@merit.edu

> So run IPv6 natively and your tunneling issues are history.

son, get a clue. i work for the first isp on the bleeping planet to
deploy native ipv6

I beg to differ. Add the word "commercial" and I might agree.

Sitting under my desk is the first system in the US with a production IP
address. (No, it's not still running. It's an old DEC Alphstation.)
ESnet has run native IPv6 as a fully supported production service for
years.

Randy is right that eliminating tunnels does not make all of the IPv6
problems go away. It just eliminates the ones caused by the use of
tunnels. The REAL problems are not going anywhere for a long time, it
ever.

2

So run IPv6 natively and your tunneling issues are history.

son, get a clue. i work for the first isp on the bleeping planet
to deploy native ipv6

I beg to differ. Add the word "commercial" and I might agree.

whoops! <blush> apologies!

eliminating tunnels does not make all of the IPv6 problems go away.
It just eliminates the ones caused by the use of tunnels.

in and of itself, this is a good thing. tunnels suck caterpillar snot.

The REAL problems are not going anywhere for a long time, if ever.

indeed, many will be with us for a long time. but there are a bunch we
could knock off in a few years
  o dual stack backbones (and it's as much the vendors as the isps here)
  o dual stack consumer cpe
  o routers that hold 2m routes *with churn* from enterprise to backbone
  o test equipment to differentiate vendor hot air from actual
    performance
  o nat-pt with standardized algs for at least dns, smtp, http, sip, and
    rtp

randy

3

–>> This is on my top 3 hot topics. And make it works both way, v4 to v6 and v6 to v4.
And also don’t call it NAT-PT. That name is dead.

  • Alain.
4

I once complained to Bjarne Stroustrup about some aspect of C++. He
replied that it was not the best possible language, but rather the
best language possible. He was dealing with programmers who were
recent converts to C; indeed, many of them had only recently been
weaned from lower-level assembler languages. (Doug McIlroy once told
me that C was the best assembler language he'd ever used. I agree with
him.) I feel much the same about IPv6.

IPv6 isn't what I wanted it to be. During the IPng directorate,
several of us (including me and at least one of the chairs) pushed very
hard for id/locator split. We lost. That was 1994; it's over and done
with. But it took 13 years from then to a (mostly) complete set of
specs and universal implementation, at least in all systems shipping
today. Even if there was universal agreement that the design was wrong
and that we should start over, I can't see it taking less than 10 years
to get back to the current level of maturity. We don't have that
long. We don't even have any guarantees that we'd get everything right
if we tried again; while we could avoid today's known pitfalls, I'm
sure there are \aleph_0 more waiting for us. To me, then, the question
is "now what?"

We have to get off of v4. We're dying the death of a thousand NATs.
What we have to do is push the responsible parties -- CPE vendors,
ISPs, router vendors, and yes, the IETF -- to fill in the holes.

    --Steve Bellovin, http://www.cs.columbia.edu/~smb

5

Randy, Alain,

    o nat-pt with standardized algs for at least dns, smtp, http, sip, and
    rtp

-->> This is on my top 3 hot topics. And make it works both way, v4 to
v6 and v6 to v4.
And also don�t call it NAT-PT. That name is dead.

For what it is worth, this is one of the things that I want
to do. I don't want to give you an impression that NAT-PT++
will solve all the IPv6 transition issues; I suspect dual stack
is a better answer. But nevertheless, the IETF needs to
produce a revised spec for the translation case. Fred and
I are organizing an effort to do this.

Jari

6

o nat-pt with standardized algs for at least dns, smtp, http, sip,
and rtp -->> This is on my top 3 hot topics. And make it works both
way, v4 to v6 and v6 to v4. And also don�t call it NAT-PT. That
name is dead.

For what it is worth, this is one of the things that I want to do.

i took you at your word the other month, so stopped worrying about
motivating it. as far as getting it through the ivtf, well, that ain't
my job any more. i gave at the office. thank you for accepting the burden.

I don't want to give you an impression that NAT-PT++ will solve all
the IPv6 transition issues

heck no. but it will enable folk to have v6-almost-only (except for one
ipv4 address) sites in a dual stack and mostly v4 world. it will allow
end site transition.

randy

7

Steven M. Bellovin wrote:
[..]

IPv6 isn't what I wanted it to be. During the IPng directorate,
several of us (including me and at least one of the chairs) pushed very
hard for id/locator split. We lost. That was 1994; it's over and done
with. But it took 13 years from then to a (mostly) complete set of
specs and universal implementation, at least in all systems shipping
today.

[..]

The good thing about the current state of IPv6 is though that
applications have the following:
- 128bits source address
- 128bits destination address

and in many cases they are now also AF independent due to getaddrinfo(),
though there will always be some dependent code in their unfortunately.

Why is the above good? Well, the application doesn't further really care
about how the packets are sent from source to destination. As such those
bits are now identifiers already. The OS can change them and do whatever
it wants with them, eg it could change them to something which is
available only on the link, tell the other end to do the same when it
receives them to make them identical when sent from the source application.

This should provide for a pretty good outcome in a couple of years where
next the second biggest "problem" of the current Internet will be solved
(the first being 32bits not being enough to address all hosts): too many
DFZ routes.

That will require a id/locator split, or IMHO better mentioned using
those 128bits as both ID's and locators. It will need a signaling
protocol for mentioning when something is an ID and when something is a
locator and how to get back to an ID, but that magic should not be too
hard to do and can be done both in the endhost and in middle boxes.

As such, IPv6 has already solved the currently biggest problem: there is
enough address space. Applications are mostly ready for this and so are
Operating Systems. Now the web should follow, and while the IPv6 DFZ
grows (it is still <900 routes) we will have enough time to create the
ID/LOC system that ISP operators and Enterprise operators will accept.
Especially that 'acceptance' is a big problem it seems and that is mosly
a political issue, not a technical one.

Btw, ram@iab.org if you want to join in on those discussions.

Greets,
Jeroen

8

Jeroen Massar wrote:

Btw, ram@iab.org if you want to join in on those discussions.
  
Correction: rrg@psg.com is where everything has moved, according to the list owners.

Eliot

9

The problem with NAT-PT (translating between IPv6 and IPv4 similar to IPv4 NAT) was that it basically introduces all the NAT ugliness that we know in IPv4 into the IPv6 world. Rather than "solving" this issue by trying harder, I would like to take the IETF to adopt the following approach:

1. for IPv6-only hosts with modest needs: use an HTTPS proxy to relay TCP connections

2. for hosts that are connected to IPv6-only networks but with needs that can't be met by 1., obtain real IPv6 connectivity tunneled on-demand over IPv6

The advantage of 1. is that proxies and applications that can use proxies are already in wide use. The advantage of 2. is that it provides real IPv4 connectivity without compromises. Different hosts (even on the same subnet) can have different IPv4 connectivity (NAT/no NAT, firewalled/unfirewalled) without having to provision the complete path between the user and the edge of the network specifically for that type of connectivity. And no lost addresses for subnetting etc.

10

Iljitsch,

Tunneling is great, but it requires to allocate an IPv4 address… that I may not have in the first place.

  • Alain.
11

1. for IPv6-only hosts with modest needs: use an HTTPS proxy to relay TCP connections

2. for hosts that are connected to IPv6-only networks but with needs that can't be met by 1., obtain real IPv6 connectivity tunneled on-demand over IPv6

The advantage of 1. is that proxies and applications that can use proxies are already in wide use. The advantage of 2. is that it provides real IPv4 connectivity without compromises. Different hosts (even on the same subnet) can have different IPv4 connectivity (NAT/no NAT, firewalled/unfirewalled) without having to provision the complete path between the user and the edge of the network specifically for that type of connectivity. And no lost addresses for subnetting etc.

However, Number 2 does not solve the need for an IPv6 only host to talk to an IPv4 only host
for some purpose other than TCP things that can be fed through an HTTPS proxy.

Owen

12

And make it works both way, v4 to v6 and v6 to v4.
And also don't call it NAT-PT. That name is dead.

For what it is worth, this is one of the things that I want
to do. I don't want to give you an impression that NAT-PT++
will solve all the IPv6 transition issues; I suspect dual stack
is a better answer. But nevertheless, the IETF needs to
produce a revised spec for the translation case. Fred and
I are organizing an effort to do this.

The problem with NAT-PT (translating between IPv6 and IPv4 similar to
IPv4 NAT) was that it basically introduces all the NAT ugliness that
we know in IPv4 into the IPv6 world.

NAT grew out of need. It didn't grow up in the IETF. We did have a NAT WG, to document, define common terminology and guidelines. We took a lot of heat for just documenting what was out there. The marketplace resulted in the success of NAT. Even if there had been limitless address space, it's unlikely NAT would have been avoided.

Rather than "solving" this issue
by trying harder, I would like to take the IETF to adopt the
following approach:

1. for IPv6-only hosts with modest needs: use an HTTPS proxy to relay
TCP connections

So your fobia over all things NAT is so deep that you would insist on the use of a SOCKS-like mechanism, breaking end-to-end connectivity, to avoid implementing NAT of any sort. Pardon me for thinking this is a stretch.

2. for hosts that are connected to IPv6-only networks but with needs
that can't be met by 1., obtain real IPv6 connectivity tunneled on- demand over IPv6

Add more devices in the path, resulting in a tortured "end-2-end" that has lots of points of failure, and lots of state in the network for those tunnel endpoints, timeouts on same, etc.

I fail to see how your proposals preserve the end-to-end nature of the Internet in any meaningful way. You've gone a long way to find something, anything, that can take the place of NAT, but in so doing, you've proposed solutions which do not appreciably differ in effect on the function of the Internet.

13

NAT grew out of need. It didn't grow up in the IETF. We did have a NAT
WG, to document, define common terminology and guidelines. We took a lot
of heat for just documenting what was out there. The marketplace
resulted in the success of NAT. Even if there had been limitless address
space, it's unlikely NAT would have been avoided.

nat is not a technology, it is the anti-$deity, at least to some. the
ivtf loves to throw out multiple confusing and competing technologies
and say "let the market decide." but it somehow has had very deaf ears
when the market decided nat in a very big way. this is not to say i
would want a nat to marry my brother!

but, ome months back, some wiser heads in the ivtf listened and agreed
that nat-pt (no, alain, i will not be silly and let people force me to
confuse things by calling it something else), is seriously required even
though it is disgusting to us all. thank you russ and jari; and i am
sure others will climb on the bandwagon and wave flags.

the alternatives are more disgusting, and lack of nat-pt is a serious
impediment to ipv6 deployment, a critical one in a world of ipv4 address
space scarcity.

for an example of the problems of public proxies, as Jeffrey Streifling
said (in http://www.civil-tongue.net/clusterf/ wiki),
  o Email/SMTP is a mandatory application
  o Everyone needs to be able to send email to arbitrary recipients,
    i.e. everyone else
  o But, due to SPAM, no one can run an open SMTP relay
  o So all IPv6 sites need to have the ability to SMTP to arbitrary IPv4
    sites
  o Therefore everyone needs private dual stack relay until the world is
    all dual stack SMTP

randy

14
  • Alain.
15

Kevin Oberman wrote:

Randy is right that eliminating tunnels does not make all of the IPv6
problems go away. It just eliminates the ones caused by the use of
tunnels. The REAL problems are not going anywhere for a long time, it
ever.

It would be nice to see some evidence of some forward motion but I don't
see any. The vendors seem to point at a lack of demand and the ISPs
claim a lack of support from the vendors and/or not customer demand. If
the ISPs tried to deploy it for themselves then perhaps this current
impasse could be broken and the current shortcomings would then have
some visibility with the vendors and that might encourage the IETF to
address the real issues.

A quick look at some of the usual suspects shows not much consumption of
their own dog food.

<http://www.mrp.net/ISP.html> although the R&E community isn't much
better <http://www.mrp.net/Internet2.html>.

Mark.

16

It would be nice to see some evidence of some forward motion but I don't
see any. The vendors seem to point at a lack of demand and the ISPs
claim a lack of support from the vendors and/or not customer demand.

It's going to get real interesting, since (in general):

1) Customers aren't going to ask for IPv6 (it's not their problem)
2) ISP's may plan a few years out, but don't make capital commitments
    until they're absolutely required.
3) It takes most vendors 3 to 6 months to move requirements through
    marketing and 1 year plus for engineering and chip design.

Alas, this particular feature set (functional IPv6 and transition tools)
is not just one new protocol feature or option; it's an order of magnitude
more complex and will take ISP's months (or even years) to deploy.

It's amazing that got the need for the new protocol right more than a
decade ago, but seemed to have left all the details to the last minute.

If the ISPs tried to deploy it for themselves then perhaps this current
impasse could be broken and the current shortcomings would then have
some visibility with the vendors and that might encourage the IETF to
address the real issues.

Agreed.

A quick look at some of the usual suspects shows not much consumption of
their own dog food.
...
<http://www.mrp.net/ISP.html>

Very nice chart!
/John

17

John Curran wrote:

It would be nice to see some evidence of some forward motion but I don't
see any. The vendors seem to point at a lack of demand and the ISPs
claim a lack of support from the vendors and/or not customer demand.

It's going to get real interesting, since (in general):

1) Customers aren't going to ask for IPv6 (it's not their problem)

Well some do :slight_smile: but in general it's just the plumbing that no one cares
about.

2) ISP's may plan a few years out, but don't make capital commitments
    until they're absolutely required.

Yes but many ISPs would be using hardware that the vendors claim is
compliant so why not test their claims and start submitting bug reports?

Of more concern would be the operations and management software, which
probably doesn't exist. This probably means that right now any
deployment would need to focus on the ISP itself rather than their
customers. Although some customers are happy to beta test just about
anything :slight_smile:

Alas, this particular feature set (functional IPv6 and transition tools)
is not just one new protocol feature or option; it's an order of magnitude
more complex and will take ISP's months (or even years) to deploy.

These are the same ISPs and vendors that seem to have managed to deploy
MPLS in a more rapid fashion.

It's amazing that got the need for the new protocol right more than a
decade ago, but seemed to have left all the details to the last minute.

I hope we're not waiting to see what happens at the end of that minute.

Mark.

18

That's was very different circumstance: "See, if we light up our nationwide
and metro wavelengths with MPLS, we can not only run the cool Internet
stuff over it, but we can move all the intermarket/interswitch voice trunks
over it, and save $$ and will make any investment back real pronto. Yep,
I've got the numbers right here. Great, thanks for your help with this!"

IPv6 is: "Well, umm, there's this IP assignment team, and ah.. no, I mean
Internet Protocol, not the legal department. Yes, those two guys, right across
from the abuse desk. Yep, the spam guys. Anyway, they say there's a real
issue coming up soon, but we're not really sure when, and what?? Yes, it's
likely to be past your tenure here, but still, we need to spend $$ now to be
ready for this thing, and we're not really sure what the new architecture is
yet. Huh? No, I don't really know what our competitors are doing, but I'm
sure that... Okay, yep, I understand. I'll send it all in an email. Who else
should I send it to? Hello? Hello? Can you hear me now?"

:wink:
/John

p.s. Apologies in advance to anyone I've worked with, IP registration folks
       in every ISP, and for anyone who's ad tag line I may have borrowed...

19

The problem with NAT-PT (translating between IPv6 and IPv4 similar to
IPv4 NAT) was that it basically introduces all the NAT ugliness that
we know in IPv4 into the IPv6 world.

NAT grew out of need. It didn't grow up in the IETF. We did have a NAT WG, to document, define common terminology and guidelines. We took a lot of heat for just documenting what was out there. The marketplace resulted in the success of NAT. Even if there had been limitless address space, it's unlikely NAT would have been avoided.

And how exactly does that relate to the discussion at hand?

For the purpose of this particular discussion, NAT in IPv4 is basically a given: coming up with an IPv4-IPv6 transition mechanism that only works with if no IPv4 NAT is present both defeats the purpose (if we had that kind of address space we wouldn't have a problem in the first place) and it's completely unrealistic.

The issue is that introducing NAT in IPv6, even if it's only in the context of translating IPv6 to IPv4, for a number of protocols, requires ALGs in the middle and/or application awareness. These things don't exist in IPv6, but they do exist in IPv4. So it's a better engineering choice to have IPv4 NAT than IPv6 NAT.

1. for IPv6-only hosts with modest needs: use an HTTPS proxy to relay
TCP connections

So your fobia over all things NAT is so deep that you would insist on the use of a SOCKS-like mechanism, breaking end-to-end connectivity, to avoid implementing NAT of any sort. Pardon me for thinking this is a stretch.

I don't see the problem with proxying, except that it only works for TCP. Yes, you need a box in the middle, but that's true of any solution where you have an IPv6-only host talk to an IPv4-only host. If both sides use a dual stack proxy, it's even possible to use address-based referrals. E.g., the IPv4 host asks the proxy to set up a session towards 2001:db8:31::1 and voila, the IPv4 host can talk to the IPv6 internet. Not possible with a NAT-PT like solution.

2. for hosts that are connected to IPv6-only networks but with needs
that can't be met by 1., obtain real IPv6 connectivity tunneled on- demand over IPv6

Add more devices in the path, resulting in a tortured "end-2-end" that has lots of points of failure, and lots of state in the network for those tunnel endpoints, timeouts on same, etc.

Apparently these downsides aren't big enough to stop the use of PPPoE.

The advantage is that you can have an IPv6-only routed network. This at the very least avoids having to provision both protocols throughout the network, and probably avoids a lot more complexity that is necessary in typical IPv4 networks (NAT hole punching etc).

I fail to see how your proposals preserve the end-to-end nature of the Internet in any meaningful way. You've gone a long way to find something, anything, that can take the place of NAT, but in so doing, you've proposed solutions which do not appreciably differ in effect on the function of the Internet.

Tunneling IPv4 over IPv6 is a lot cleaner than translating between the two. It preserves IPv4 end-to-end. :slight_smile:

This can indeed be used to avoid NAT if you use public IPv4 addresses, but it's also the solution that incurs the least amount of NAT issues if you don't, because those issues stay in IPv4 where they're well known.

PS. someone told me that work on tunneling IPv4 over IPv6 is under way in the IETF under the name "softwires".

20

Thus spake "Iljitsch van Beijnum" <iljitsch@muada.com>

And make it works both way, v4 to v6 and v6 to v4.
And also don�t call it NAT-PT. That name is dead.

For what it is worth, this is one of the things that I want
to do. I don't want to give you an impression that NAT-PT++
will solve all the IPv6 transition issues; I suspect dual stack
is a better answer. But nevertheless, the IETF needs to
produce a revised spec for the translation case. Fred and
I are organizing an effort to do this.

The problem with NAT-PT (translating between IPv6 and IPv4
similar to IPv4 NAT) was that it basically introduces all the NAT
ugliness that we know in IPv4 into the IPv6 world.

There is no "IPv6 world". I've heard reference over and over to how developers shouldn't add "NAT support" into v6 apps, but the reality is that there are no "v6 apps". There are IPv4 apps and IP apps that are version agnostic. The NAT code is there and waiting to be used whether the socket underneath happens to be v4 or v6 at any given time.

Yes, ideally the NAT code wouldn't get used if the socket were v6. The other thing is NAT is only a small fraction of the problem; most of the same code will be required to work around stateful firewalls even in v6.

Rather than "solving" this issue by trying harder, I would like to
take the IETF to adopt the following approach:

1. for IPv6-only hosts with modest needs: use an HTTPS proxy
to relay TCP connections

2. for hosts that are connected to IPv6-only networks but with
needs that can't be met by 1., obtain real IPv6 connectivity
tunneled on-demand over IPv6

Neither solves the problem of v6-only hosts talking to v4-only hosts.

The fundamental flaw in the transition plan is that it assumes every host will dual-stack before the first v6-only node appears. At this point, I think we can all agree it's obvious that isn't going to happen.

NAT-PT gives hosts the _appearance_ of being dual-stacked at very little up-front cost. It allows v6-only hosts to appear even if there still remain hosts that are v4-only, as long as one end or the other has a NAT-PT box. The chicken and egg problem is _solved_. When v4-only users get sick of going through a NAT-PT because it breaks a few things, that will be their motivation to get real IPv6 connectivity and turn the NAT-PT box off -- or switch it around so they can be a v6-only site internally.

The alternative is that everyone just deploys multi-layered v4 NAT boxes and v6 dies with a whimper. Tell me, which is the lesser of the two evils?

S

Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking