Subject: Re: chicago IETF IPv6 connectivity

From: Keith Moore <[email-masked]>
Date: Sun, 01 Jul 2007 00:49:11 -0400

> On the theory that the ietf meeting net is for production services,
> wouldn't it make sense to have the time to cut over to pure ipv6 be
> when production use of ipv4 becomes minimal?
>
> No?
No, because that presumes that IPv6 will be used for production only
when it mostly replaces IPv4.  It's more realistic to assume that the
first production uses of IPv6 are those for which IPv4 is not
satisfactory for one reason or another - e.g. lack of available
addresses, inability to use the desired applications in the presence of
NAT, etc.

OTOH, the IETF meeting net has never been entirely for production
services - there's also been something of a history of using it to eat
our own dogfood and learning how to make it tasty enough that we like
it.   Remote video and audio access via multicast, wireless LANs, etc.

Keith

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sun, 1 Jul 2007 14:36:01 +0900 (JST)

> > Maybe we are getting to the point in time where we should only have  
> > IPv6 at IETF meetings
> 
> good luck. Until the ISPs and our corporate networks deploy it, we  
> can't go there.

	to use legacy protocol like IPv4 :-) you can use IPv6-to-IPv4
	tranlators like NAT-PT or RFC3142.  their scalability is no worse
	than IPv4-to-IPv4 NAT.

itojun

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sun, 1 Jul 2007 21:32:06 +0900 (JST)

> > Maybe we are getting to the point in time where we should only have IPv6 
> > at IETF meetings or it that's premature run IPv4 behind a couple of 
> > layers of NAT.
> 
> On the theory that the ietf meeting net is for production services, wouldn't 
> it make sense to have the time to cut over to pure ipv6 be when production use
> of ipv4 becomes minimal?

	maybe we can have the default "IETF61" SSID be pro-IPv6, and SSID
	"legacy" be IPv4-only :-P

itojun

---

From: Dave Crocker <[email-masked]>
Date: Sun, 01 Jul 2007 06:34:25 -0700

> 	"legacy" be IPv4-only :-P

Ahh, well.  That moves the change from being coercive to being cool.

Good marketing approach.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 1 Jul 2007 07:49:00 -0700

At 2:36 PM +0900 7/1/07, Jun-ichiro itojun Hagino wrote:
>	tranlators like NAT-PT or RFC3142.

NAT-PT (RFC 2766) is being moved to Historic status. RFC 3142 is 
Informational. Without a standards-track method for people to use 
IPv4, changing a production network to IPv6 seems unwise.

>their scalability is no worse
>	than IPv4-to-IPv4 NAT.

That may be true, but it is also irrelevant, given that the current 
production network doesn't use IPv4 NAT at all.

--Paul Hoffman, Director
--VPN Consortium

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Mon, 02 Jul 2007 00:02:29 +0900

>IPv4, changing a production network to IPv6 seems unwise.

	RFC status does not have direct connection with "being implemented" or
	"being deployed" (see all the W3C standards which did not originate
	in IETF).

	at N+I tokyo we have been using RFC2766/3142 for IPv6-only net cafe
	since around year 2000 or something.  in June 2007 N+I network team
	used Windows Vista official releases as the clients.

>>	their scalability is no worse than IPv4-to-IPv4 NAT.
>

	you are in ARIN region so you are enjoying vast amount of IPv4 address
	space...  come to APNIC region or LACNIC region to experience the pain.
	i pay $300/mo for PA /29, and it is a real bargain.

itojun

---

From: Jeroen Massar <[email-masked]>
Date: Sun, 01 Jul 2007 16:26:30 +0100

Paul Hoffman wrote:
> Informational. Without a standards-track method for people to use IPv4,
> changing a production network to IPv6 seems unwise.

The thing to do before thinking of removing IPv4 connectivity is too
look at which applications are actually using IPv4.
NetFlow/sniffing etc can be used to determine these organization wide.

Most likely you will come down to at least:
 - HTTP -> for which one can use a HTTP Proxy which does v4+v6
 - SMTP -> for which one can use SMTP :) (does both v4+v6)
 - IMAP/POP -> let the app handle it

In the end though one needs to have a machine somewhere which does both
IPv4 and IPv6 and translates between them. But on the Application
Protocol level, not by changing bits like NAT-PT does.

I am not sure, but is there not a draft/rfc/paper which details
something like "Common application migration path from IPv4 to IPv6"?
It is now I guess all cluttered all over the place. Maybe a Wikipedia
article would be more appropriate, outlining which protocols can be
resolved in way X and/or Y. This also allows everything to be in a
central place which pointers to the programs that can do this too.

Greets,
 Jeroen

---

From: Keith Moore <[email-masked]>
Date: Sun, 01 Jul 2007 12:46:18 -0400

> 	used Windows Vista official releases as the clients.

NAT-PT really needs to be wiped off the face of the earth.  It provides
all of the disadvantages of IPv4+NAT with all of the transition costs of
IPv6.  If there is ever any significant penetration of NAT-PT, then the
pseudo-IPv6 network will not be able to support any more kinds of
applications than the NATted IPv4 does today.

Keith

---

From: Philip Matthews <[email-masked]>
Date: Sun, 1 Jul 2007 16:31:16 -0400

I suggest starting by having a separate SSID for IPv6 only
and encouraging people to test it out.
Advertise it in the notes, on the mailing list, and elsewhere.
Ask people in the post-meeting survey whether they
have tried it, and whether it worked with their computer.

After there is a high success rate, then start migrating
the main wireless network to IPv6 only, but leave a legacy
SSID for IPv4.

This will encourage people to transition, and will shift the
focus to IPv6, while still allowing people with old computers
and operating systems to connect.

- Philip

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Mon, 2 Jul 2007 09:24:30 +0900 (JST)

> No, that moves it to being pejorative.
> 
> In any case, what is the need for separate SSID's?  Do you truly  
> intend to clutter the airspace further with another set of AP's?   
> There are effectively only three channels and you really want to use  
> all three already to provide overlapping non-interfering coverage...

	you right.  we have been running dual stack network since 1998 or
	something (Marc Blanchet should have the real answer), and we even
	supplied IPv6-to-IPv4 translators, so there should be no problem at
	all.

	I can bring in IPv6-to-IPv4 translator if necessary.  it would be an
	OpenBSD Soekris box.

itojun

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 2 Jul 2007 17:55:59 +0200

> applications than the NATted IPv4 does today.

First of all, this is the worst kind of ivory tower thinking. How am  
I supposed to run IPv6 and access the IPv4 world without a mechanism  
like NAT-PT? Killing that without providing an alternative was a very  
bad move that will come back to haunt the IETF. (And although the  
problems with NAT-PT are real, they're not THAT bad.)

And you're wrong, too. With NAT-PT and a DNS ALG in effect, you have  
NAT-incumbered access to the IPv4 world, which is not good because  
IPv6 stuff isn't built to work with NAT. But at least you have access  
to the IPv4 world. But your access to the IPv6 world is completely  
trouble free, which is the point.

The following draft should appear in due course (it's only 4 pages):

http://www.muada.com/drafts/draft-van-beijnum-v6ops-connect- 
method-00.txt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 02 Jul 2007 12:54:31 -0400

On Saturday, June 30, 2007 10:56:59 PM -0400 Fred Baker <[email-masked]> 
wrote:

>
> On Jun 30, 2007, at 9:49 PM, Bob Hinden wrote:
>
> good luck. Until the ISPs and our corporate networks deploy it, we  can't
> go there.

... and this point may be lost on some people, but most IETF participants 
do not operate their ISP's or corporate networks, and have no ability to 
change them.  Most of us come to IETF meetings to get work done, not to 
spend the week fighting to get connectivity to home because someone wants 
to use the IETF network to "encourage" someone to deploy IPv6 or any other 
new technology.

Every time I come to an IETF meeting, I lose a week or more of time on my 
regular job.  What makes that acceptable is that I can get significant 
amounts of IETF work done in that week.  Take that away, and IETf meeting 
attendance suddenly becomes counter-productive for individuals, and then 
for the organization as a whole.

The IETF network is not, and never has been, for experimentation, showing 
off new technology, or making political statements.  Please keep it that 
way.

-- Jeff

---

From: Dave Crocker <[email-masked]>
Date: Mon, 02 Jul 2007 12:42:00 -0700

> The IETF network is not, and never has been, for experimentation, 
> showing off new technology, or making political statements.  Please keep 
> it that way.

+1

d/

-- 

   Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Mon, 02 Jul 2007 16:38:02 -0400

Iljitsch van Beijnum wrote:
> First of all, this is the worst kind of ivory tower thinking. 
uh, no.  it's realistic thinking.  I've written distributed applications
before and after NAT, and the amount of additional complexity and
infrastructure required for such an application to function and scale in
the presence of NAT is staggering.  the presence of NATs in the v4
Internet has held back application development for around 10 years now.
> How am I supposed to run IPv6 and access the IPv4 world without a
> mechanism like NAT-PT? 
There are solutions for corner cases that involve address translation. 
For instance, if you have a legacy IPv4-only device, say a printer, and
you want IPv6-only hosts to be able to access it, you can put a device
in the signal path that translates between IPv6 and IPv4 and vice
versa.  It will look a lot like a NAT-PT box.  The difference is that
it's not a general purpose solution.  It only works for specific
applications that don't attach any significance to addresses.  But as
soon as you start trying to front an entire network with such a box,
you've killed the ability of that network to support certain kinds of
applications.  And if such devices get widely deployed in such a manner,
then the IPv6 network becomes just as crippled as the IPv4 network has
become.

Similarly if you are on an IPv6-only network and you want to make some
services accessible to IPv4, you can set up a tunnel between a specific
application and a point of presence on the IPv4 network. Something like
NAT-PT works in some cases, in other cases an application-specific proxy
or a SOCKS-like protocol work better.  But even if the NAT-PT like
approach is used it's not a general solution, it's something that is set
up for a particular application on a particular host and port based on
knowledge of the specific needs of that application.
> Killing that without providing an alternative was a very bad move that
> will come back to haunt the IETF. (And although the problems with
> NAT-PT are real, they're not THAT bad.)
Disagree.  All of the documentation that IETF has done on the problems
with NAT only scratches the surface.  And NAT-PT is worse than NAT,
because it promotes use of two-faced DNS which has its own set of evils
that are approximately as bad as those for NAT.
> trouble free, which is the point.
no it's not, because that assumes that a host or an application is
either purely IPv4 or IPv6, and it assumes that DNS results from IPv4
queries don't get exposed to IPv6-aware apps.  neither of those is true.
> http://www.muada.com/drafts/draft-van-beijnum-v6ops-connect-method-00.txt
I'll look for it.

Keith

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 3 Jul 2007 08:11:02 +0900 (JST)

> > showing off new technology, or making political statements.  Please keep 

	RFC1883 is not new.

itojun

---

From: Dave Crocker <[email-masked]>
Date: Mon, 02 Jul 2007 16:18:11 -0700

>>> showing off new technology, or making political statements.  Please keep 

Neither is X.400, TP0, or many other specs.  But then, that's not the issue.

The issue is operational risk.

d/

-- 

   Dave Crocker

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 3 Jul 2007 10:04:45 +0200

Did we forget the IETF motto about running code ? 

I do understand that there is a need to alleviate risks in the
operational network, so a traditional operational IPv4 network has to
be maintained until a vast majority of IETFers have assessed the proper
operation of IPv6.  

But this doesn't prevent to operate a more advanced technology
simultaneously. Someone has to start and experiment the shortcomings,
if the IETF is not doing it no body is going to do it or nobody is
going to be put any trust in a new technology. IETF has to pioneer this
as it did so far (multicast, security, IPv6, and hopefully more will
experimented at the IETF). 

Anyway, IPv6 is not experimental, it runs alright in operational
networks. 

What I think the IETF should experiment now at a wider scale is the
transition tools between IPv6 and IPv4. This would only be meaningful
if results of the experiments are published, for instance in the IETF
journal.

Regards,
Thierry.

On Mon, 02 Jul 2007 16:18:11 -0700

-- 
Thierry ERNST, PhD 
INRIA Rocquencourt France Project-Team IMARA / JRU LARA
http://www.lara.prd.fr +33 1 39 63 59 30 (office)
-- 
The coming end of the IPv4 world: http://penrose.uk6x.com

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 3 Jul 2007 16:12:07 +0200

Dave Crocker writes:
> Bob Hinden wrote:
>> IPv6 at IETF meetings or it that's premature run IPv4 behind a 
>> couple of layers of NAT.
>

IMNSHO, the sensible time is to do it when the relevant RIR runs out of 
addresses. I'm sure the IETF can get a couple of thousand IPv4 
addresses for temporary use even years after that time, but it would 
seem a little hypocritical to do so.

The network at both of IETF meetings I've attended felt a little 
archaic: abundant addresses, no paperwork, no firewall, no NAT.

Arnt

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 03 Jul 2007 08:34:51 -0700

Arnt Gulbrandsen wrote:
>>> IPv6 at IETF meetings or it that's premature run IPv4 behind a couple
>>> of layers of NAT.
>>
> addresses. I'm sure the IETF can get a couple of thousand IPv4 addresses
> for temporary use even years after that time, but it would seem a little
> hypocritical to do so.
> 

So basically, you're complaining that you came to the IETF and received
production quality Internet service?

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 3 Jul 2007 08:37:18 -0700

Why can't the people who want to use IPv4 use that and the people who want to use IPv6 use that.

If IP and appletalk can survive in the same network then IPv4 should be able to survive with IPv6.

Sounds to me as if what is really being proposed here is to shut down the IPv4 connectivity. That will cause a serious loss of productivity for me. I am going to Chicago to work and not to participate in a LAN party or an interop. There are plenty of venues where that can take place.

With 1200 attendees paying $600 plus travel to attend the meeting is costing well over a million dollars. 

I agree that we should do dog food. The fact that this experiment cannot take place is the data point.

People have to accept the data point and think through the deployment strategy more thoroughly.

Back when laptops first came out you have to buy one power brick for the US and a second one for Europe. The modern multi-voltage power supply only appeared when an Apple vice president got angry when he discovered he dd not have the right adaptor, returned to the engineering dept and told them that from now on the machine would work on any mains electricity anywhere in the world.

> -----Original Message-----
> From: Thierry Ernst [mailto:[email-masked]] 
> Sent: Tuesday, July 03, 2007 4:05 AM
> To: [email-masked]
> Subject: Re: chicago IETF IPv6 connectivity
> 
> 
> I do understand that there is a need to alleviate risks in 
> the operational network, so a traditional operational IPv4 
> network has to be maintained until a vast majority of IETFers 
> have assessed the proper operation of IPv6.  
> 
> But this doesn't prevent to operate a more advanced 
> technology simultaneously. Someone has to start and 
> expeFrom [email-masked] Tue Jul 03 11:38:57 2007
Content-class: urn:content-classes:message
Date: Tue, 3 Jul 2007 08:37:18 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Thierry Ernst" <[email-masked]>, <[email-masked]>
Cc: 
Subject: RE: chicago IETF IPv6 connectivity

Why can't the people who want to use IPv4 use that and the people who want to use IPv6 use that.

If IP and appletalk can survive in the same network then IPv4 should be able to survive with IPv6.

Sounds to me as if what is really being proposed here is to shut down the IPv4 connectivity. That will cause a serious loss of productivity for me. I am going to Chicago to work and not to participate in a LAN party or an interop. There are plenty of venues where that can take place.

With 1200 attendees paying $600 plus travel to attend the meeting is costing well over a million dollars. 

I agree that we should do dog food. The fact that this experiment cannot take place is the data point.

People have to accept the data point and think through the deployment strategy more thoroughly.

Back when laptops first came out you have to buy one power brick for the US and a second one for Europe. The modern multi-voltage power supply only appeared when an Apple vice president got angry when he discovered he dd not have the right adaptor, returned to the engineering dept and told them that from now on the machine would work on any mains electricity anywhere in the world.

> -----Original Message-----
> From: Thierry Ernst [mailto:[email-masked]] 
> Sent: Tuesday, July 03, 2007 4:05 AM
> To: [email-masked]
> Subject: Re: chicago IETF IPv6 connectivity
> 
> 
> I do understand that there is a need to alleviate risks in 
> the operational network, so a traditional operational IPv4 
> network has to be maintained until a vast majority of IETFers 
> have assessed the proper operation of IPv6.  
> 
> But this doesn't prevent to operate a more advanced 
> technology simultaneously. Someone has to start and 
> experiment the shortcomings, if the IETF is not doing it no 
> body is going to do it or nobody is going to be put any trust 
> in a new technology. IETF has to pioneer this as it did so 
> far (multicast, security, IPv6, and hopefully more will 
> Anyway, IPv6 is not experimental, it runs alright in 
> operational networks. 
> 
> What I think the IETF should experiment now at a wider scale 
> is the transition tools between IPv6 and IPv4. This would 
> only be meaningful if results of the experiments are 
> published, for instance in the IETF journal.
> 
> Regards,
> Thierry.
> 
> 
> >>>> showing off new technology, or making political 
> statements.  Please 
> >>>> keep it that way.
> >>> +1
> >> 
> >> 	RFC1883 is not new.
> >
> >

---

From: "Clint Chaplin" <[email-masked]>
Date: Tue, 3 Jul 2007 12:04:36 -0700

I've been watching this debate for a while, and all the previous
debates every time this subject comes up.

IETF is no longer a single subject group.  Very few participants are
up to date with everything that IETF is working on, and many newer
participants are participating in what I would characterize as "edge"
areas: capwap, manet, and the like.

I suspect (and I fall into this category) that many of these newer
participants are not IP wizards; they're here to do work in other
areas.  Requiring them to participate in testing a new infrastructure
that they are not familiar with would be counterproductive to getting
their work done.

Is it OK to have an IPv6 infrastructure available to play with and
test?  Absolutely!  Just don't mandate it yet.

-- 
Clint (JOATMON) Chaplin
Principal Engineer
Corporate Standardization (US)
SISA

---

From: Douglas Otis <[email-masked]>
Date: Tue, 3 Jul 2007 12:13:22 -0700

On Jul 3, 2007, at 8:34 AM, Joel Jaeggli wrote:

> Arnt Gulbrandsen wrote:
>>
>> IMNSHO, the sensible time is to do it when the relevant RIR runs  
>> out of addresses. I'm sure the IETF can get a couple of thousand  
>> IPv4 addresses for temporary use even years after that time, but  
>> it would seem a little hypocritical to do so.
>>
> So basically, you're complaining that you came to the IETF and  
> received production quality Internet service?

Do IETF networks add missing IPv6 root glue?  If so, would this be  
beyond production quality?

-Doug

---

From: Keith Moore <[email-masked]>
Date: Tue, 03 Jul 2007 15:55:43 -0400

> that they are not familiar with would be counterproductive to getting
there is NOBODY working in IETF for whom familiarity with IP, including
IPv6, is not essential.
whether they realize this is a different question.  but you cannot do
competent work in IETF without a basic understanding of the TCP/IP
protocol stack.

Keith

---

From: "Clint Chaplin" <[email-masked]>
Date: Tue, 3 Jul 2007 13:18:09 -0700

adsl mib
enum
geopriv
mediactrl
speechsc
emu
kitten
ltans
openpgp
pkix

Oh, and TCP isn't the only protocol in use.  UDP, for instance, is the
protocol used by Kerberos.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 04 Jul 2007 05:25:13 +0900

>beyond production quality?

	if I were to provide RFC3142 IPv6-to-IPv4 TCP relaying gateway, I will
	be using "totd" tricky recursive DNS server.  if you put it in
	/etc/resolv.conf or something alike, you will get translated
	AAAA records whenever there's no real AAAA record present for a DNS
	name, and IPv6 TCP traffic will be re-connected into IPv4..

	there still are some questions remain:
	- on *BSDs we do not have UDP relaying gateway, because TCP relaying
	  gateway relies upon *BSD tcpcb structure.  Yokogawa sells commercial
	  device which does UDP relaying as well, so maybe yokogawa guys want
	  to speak up.
	- if you run named or some DNS resolver which caches old results,
	  your DNS cache may be filled with the translated results.  it may
	  or may not cause problems.  the DNS TTL below shows that totd gives
	  the same TTL as the original A records, it should be reduced to like
	  0 or 10 seconds when translation happens.
	  with *BSD implementation there's no caching code in libc resolver.
	  with Apple MacOS X there may be some cache but I have never
	  experienced any issues.  so there's no cache I suppose, or cache
	  entries are associated with the information source DNS server.
	  I have no idea about Microsoft OSes nor Linux.

itojun

			  | IPv6-over-IPv4 tunnel (MTU = 1280)
garlic.itojun.org	coconut.itojun.org
  |2			  |1
==+=======================+== wireless segment
  |	  192.168.0.0/24, 2001:240:501:1::/64
wireless clients

- DHCPv4 daemon will give wireless clients IPv4 address, DNS server IPv4
  address (192.168.0.2), but NO IPv4 default gateway
- IPv6 router advertisement will make wireless clients configure itself with
  IPv6 address(es) and IPv6 default gateway
- totd runs on garlic.itojun.org (192.168.0.2)
- totd returns translated responses to clients when asked about DNS names
  without AAAA record associated with it (such as a.root-servers.net).
  totd will not trick you if the DNS name has AAAA associated with it
  (www.kame.net).
- TCP traffic to 2001:240:501:ffff::/64 will get sucked by garlic.itojun.org
- garlic.itojun.org will re-connect IPv6 TCP to IPv4 TCP

itojun[garlic:~] dig @192.168.0.2 a.root-servers.net. a

; <<>> DiG 9.3.4 <<>> @192.168.0.2 a.root-servers.net. a
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13668
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;a.root-servers.net.            IN      A

;; ANSWER SECTION:
a.root-servers.net.     604225  IN      A       198.41.0.4

;; AUTHORITY SECTION:
root-servers.net.       604217  IN      NS      a.root-servers.net.
root-servers.net.       604217  IN      NS      f.root-servers.net.
root-servers.net.       604217  IN      NS      j.root-servers.net.
root-servers.net.       604217  IN      NS      k.root-servers.net.

;; Query time: 27 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: Wed Jul  4 05:18:25 2007
;; MSG SIZE  rcvd: 180

itojun[garlic:~] dig @192.168.0.2 a.root-servers.net. aaaa

; <<>> DiG 9.3.4 <<>> @192.168.0.2 a.root-servers.net. aaaa
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30068
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;a.root-servers.net.            IN      AAAA

;; ANSWER SECTION:
a.root-servers.net.     604798  IN      AAAA    2001:240:501:ffff::c629:4

;; AUTHORITY SECTION:
root-servers.net.       604790  IN      NS      a.root-servers.net.
root-servers.net.       604790  IN      NS      f.root-servers.net.
root-servers.net.       604790  IN      NS      j.root-servers.net.
root-servers.net.       604790  IN      NS      k.root-servers.net.

;; Query time: 88 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: Wed Jul  4 05:08:52 2007
;; MSG SIZE  rcvd: 192

itojun[garlic:~] dig @192.168.0.2 www.kame.net. a

; <<>> DiG 9.3.4 <<>> @192.168.0.2 www.kame.net. a
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61674
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.kame.net.                  IN      A

;; ANSWER SECTION:
www.kame.net.           86400   IN      A       203.178.141.194

;; AUTHORITY SECTION:
kame.net.               86400   IN      NS      ns1.itojun.org.
kame.net.               86400   IN      NS      orange.kame.net.

;; ADDITIONAL SECTION:
ns1.itojun.org.         3600    IN      A       221.249.121.227
ns1.itojun.org.         3600    IN      AAAA    2001:240:501::53:0

;; Query time: 306 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: Wed Jul  4 05:19:06 2007
;; MSG SIZE  rcvd: 175

itojun[garlic:~] dig @192.168.0.2 www.kame.net. aaaa

; <<>> DiG 9.3.4 <<>> @192.168.0.2 www.kame.net. aaaa
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4861
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.kame.net.                  IN      AAAA

;; ANSWER SECTION:
www.kame.net.           86400   IN      AAAA    2001:200:0:8002:203:47ff:fea5:3085

;; AUTHORITY SECTION:
kame.net.               86399   IN      NS      orange.kame.net.
kame.net.               86399   IN      NS      ns1.itojun.org.

;; ADDITIONAL SECTION:
ns1.itojun.org.         3600    IN      A       221.249.121.227
ns1.itojun.org.         3600    IN      AAAA    2001:240:501::53:0

;; Query time: 43 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: Wed Jul  4 05:19:07 2007
;; MSG SIZE  rcvd: 187

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 3 Jul 2007 15:44:11 -0700

I certainly do not need to work out how to persuade my Checkpoint client to talk to my corporate VPN via  IPv6 in order to contribute to KEYPROV, DKIM or any of the other WGs I will be attending.

The application is miserable enough at the best of times without additional issues. And since the policy configuration is verified by the gateway I cannot change the policy unilateraly.

The point about eating dog food is not to order the salespeople to eat the dog food or else. If the salespeople refuse to eat the dog food you are meant to go back and fix it. The approach being suggested here is to tell the salespeople to eat it and like it.

> From: Keith Moore [mailto:[email-masked]] 
> Sent: Tuesday, July 03, 2007 3:56 PM
> To: Clint Chaplin
> Cc: [email-masked]
> there is NOBODY working in IETF for whom familiarity with IP, 
> including IPv6, is not essential.
> whether they realize this is a different question.  but you 
> cannot do competent work in IETF without a basic 
> understanding of the TCP/IP protocol stack.
> 
> Keith
> 
>

---

From: Douglas Otis <[email-masked]>
Date: Tue, 3 Jul 2007 16:38:52 -0700

On Jul 3, 2007, at 3:44 PM, Hallam-Baker, Phillip wrote:

> The point about eating dog food is not to order the salespeople to  
> eat the dog food or else. If the salespeople refuse to eat the dog  
> food you are meant to go back and fix it. The approach being  
> suggested here is to tell the salespeople to eat it and like it.

For most startups, it is not the quality of the dog food that  
matters.  It is the quality of the sales people.  No one expects a  
first version of anything to not have bugs. : )

-Doug

---

From: Keith Moore <[email-masked]>
Date: Tue, 03 Jul 2007 22:19:53 -0400

> I certainly do not need to work out how to persuade my Checkpoint client to talk to my corporate VPN via  IPv6 in order to contribute to KEYPROV, DKIM or any of the other WGs I will be attending.
point taken.  but you do need to know basics of how IPv6 works to
competently participate in any IETF working group.  you might think that
IPv6 is irrelevant, but it's not, because people are constantly making
IPv4-specific assumptions in higher-level protocol designs without
realizing it.
> The application is miserable enough at the best of times without additional issues. And since the policy configuration is verified by the gateway I cannot change the policy unilateraly.
if you work for a company that forces you to use crappy software, I feel
for you.  but hey, we all have our burdens to bear. 
> The point about eating dog food is not to order the salespeople to eat the dog food or else. If the salespeople refuse to eat the dog food you are meant to go back and fix it. The approach being su…
what do salespeople have to do with IETF?

---

From: Keith Moore <[email-masked]>
Date: Tue, 03 Jul 2007 23:16:24 -0400

>> competent work in IETF without a basic understanding of the TCP/IP
my point stands.  participants in all of these groups need to understand
basics of the TCP/IP protocol stack (including UDP).  for instance, you
can't write a decent MIB without understanding how SNMP works and to do
that you need to understand the consequences of its design choices
(including how it uses UDP).  similarly, you can't do a competent job
designing new DNS records or using existing ones without understanding
the protocol limitations of DNS, which follow to a large degree from
quirks in IP and UDP.   You certainly can't do competent Internet
security work without understanding how the information is going to be
packetized, routed, and sent around the network, and reassembled - i.e.
without understanding IP.

I once had a working group where the participants insisted that they
layer everything on top of HTTP because they didn't understand TCP and
weren't willing to learn.  They didn't even really understand HTTP or
its limitations, for instance, in being pretty much a
remote-procedure-call mechanism (which has certain inherent
inefficiencies) or being poor at handling asychronous notifications
(which they needed).  All they knew was that HTTP had APIs that they
could call.  And they didn't know how to use those.  And what they
produced was a disaster.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 3 Jul 2007 21:37:42 -0700

> Hallam-Baker, Phillip wrote:
> The point about eating dog food is not to order the
> salespeople to eat the dog food or else. If the salespeople
> refuse to eat the dog food you are meant to go back and fix it.

Indeed.

> The approach being suggested here is to tell
> the salespeople to eat it and like it.

It's orthogonal, and irrelevant. Salespeople do not care how the dog
food tastes. If it sells, they will eat it and pretend they like it. If
the dogs don't like the food, there is no point having the salespeople
eat it.

Michel.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 4 Jul 2007 17:32:28 -0700

Well you say that you can't do this and that without knowing what you are doing.

A counterexample is the fact that the basic architecture of the most widely used security protocol we have in use today were set by people who did not know what they were doing. They had the good sense to later hire people who did but they had already made the critical choices at that point.

Sure we beat them up for getting the security design wrong (he's talking about an integrity attack, Marc), but they did make a design choice that none of the rest of us who knew better would have done that has in hindsight turned out to be completely right.

A similar set of issues surrounded the Web. The critical invention was 404 Not Found. Scruffy links were the wrong way to do it in 1992 but today we understand that only scruffy can work.

Architecture is about abstraction. Knowing what you can forget is the really important part.

> Sent: Tuesday, July 03, 2007 11:16 PM
> To: Clint Chaplin
> Cc: [email-masked]
> my point stands.  participants in all of these groups need to 
> understand basics of the TCP/IP protocol stack (including 
> UDP).  for instance, you can't write a decent MIB without 
> understanding how SNMP works and to do that you need to 
> understand the consequences of its design choices (including 
> how it uses UDP).  similarly, you can't do a competent job 
> designing new DNS records or using existing ones without 
> understanding the protocol limitations of DNS, which follow 
> to a large degree from
> security work without understanding how the information is 
> going to be packetized, routed, and sent around the network, 
> and reassembled - i.e.
> I once had a working group where the participants insisted 
> that they layer everything on top of HTTP because they didn't 
> understand TCP and weren't willing to learn.  They didn't 
> even really understand HTTP or its limitations, for instance, 
> in being pretty much a remote-procedure-call mechanism (which 
> has certain inherent
> inefficiencies) or being poor at handling asychronous 
> notifications (which they needed).  All they knew was that 
> HTTP had APIs that they could call.  And they didn't know how 
> to use those.  And what they produced was a disaster.
> 
> 
>

---

From: Keith Moore <[email-masked]>
Date: Wed, 04 Jul 2007 21:08:47 -0400

you and I obviously inhabit different planets.  please don't tell me any
more about the one you live on.

Keith

---

From: Tony Li <[email-masked]>
Date: Sun, 1 Jul 2007 13:49:42 -0700

Tony

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 3 Jul 2007 16:39:03 -0400

Le 07-07-01 à 20:24, Jun-ichiro itojun Hagino a écrit :
> 	something (Marc Blanchet should have the real answer),

Chicago IETF 42nd. Aug 1998.

Marc.

-----
IPv6 book: Migrating to IPv6, Wiley, 2006, http://www.ipv6book.ca

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 5 Jul 2007 18:35:06 +0200

> uh, no.  it's realistic thinking.

Sorry, I have to disagree. Realistic thinking is when there is a  
messy solution, you create a non-messy solution first before killing  
the messy one.

> I've written distributed applications

...with no end in sight.

> then the IPv6 network becomes just as crippled as the IPv4 network has

Well, that depends. I grant you that this is certainly something that  
_could_ happen. The risk here is that if we provide something  
relatively simple that works for a relatively limited set of  
applications/protocols, people will want to apply this mechanism to  
additional applications/protocols, and then the trouble starts. But  
is not having the mechanism in the first place the best solution to  
avoid this?

There are basically two types of applications/protocols: the simple  
client/server ones (that work through NAT without changes) and  
anything else that's more complex. In my opinion, it would be a huge  
win to allow the former to work through some kind of IPv6-IPv4  
translation because then all the hosts that only use these types of  
applications don't need IPv4 anymore and life becomes simple for the  
people who need to manage these hosts. The solution for hosts that  
need to do more complex stuff all the time is obvious: those need an  
IPv4 address.

This leaves the case of hosts who need to run more complex stuff some  
of the time unaddressed. I think some sort of IPv4 address leasing  
tunneled over IPv6 would work here. This has a number of advantages:

- the host has an actual IPv4 address, so no weirdness because the  
two ends see different IP versions (avoiding NAT for the IPv4 part is  
left as an exercise for the reader)
- the IPv4 address is only used when needed so the number of  
addresses is much smaller than with traditional IPv4 provisioning  
(more like dial-up)
- there is no need to subnet, the IPv4 addresses can be used  
individually (also like dial-up)

>> http://www.muada.com/drafts/draft-van-beijnum-v6ops-connect- 

http://www.ietf.org/internet-drafts/draft-van-beijnum-v6ops-connect- 
method-00.txt

Iljitsch

---

From: Keith Moore <[email-masked]>
Date: Thu, 05 Jul 2007 14:57:37 -0400

> people who need to manage these hosts. 
that's the kind of thinking that polluted the IPv4 network with NATs. 
the problem is that those simple applications share the same hosts and
network that the other applications do.  if you put devices in the
network that only solve problems for the simple applications, then you
get a network that can only run simple applications.

---

From: Keith Moore <[email-masked]>
Date: Thu, 05 Jul 2007 18:54:53 -0400

>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> At least, without tunneling/overlays. And that's exactly the kind of 
> network we now have and will continue to have for the forseeable 
> future.  Moreover, I would claim that NAT is not even the biggest 
> problem.
>
> (I'm always perplexed by the semi-annual NAT wars on the IETF list 
> because rarely are firewalls given comparable billing even though I 
> suspect they cause far more problems for NOCs.  Certainly both they 
> and NAT boxes cause silent, mysterious failures that cause users to 
> think the network is broken.  Yet *lots* of people want their part of 
> the network to be a gated community.)
>   
Indeed, NATs aren't the only problem we're facing.  Interception proxies
and using IP addresses as policy tokens are also huge problems.  But
it's hard to argue that networks shouldn't have some policy, it's just
that we haven't given them better tools to enforce it.   And from an
architectural perspective, address translation is clearly a dead end. 
One of the reasons we argue against NATs is not that there aren't other
major problems, it's that people haven't managed to get the message on
NATs yet.  If we can't make the case against NATs within IETF, how can
we even begin to address the thornier cases?  (of course, what happens
is that the thornier cases are used to justify the continued existence
of NATs - which is a bit like using the existence of evil to justify
doing more evil)
> The Internet-of-the-future is shaping up to be a collection of home 
> and enterprise networks linked by port 443.  And I see no reason to 
> believe that IPv6 is going to change that.
>   
I suppose we should stop trying to design better networks, then?  Maybe
if everyone who believes that would stop participating in IETF then the
dozen or so of us remaining could get some useful work done.  :)

For what it's worth, there seems to be a long history in the Internet
(and other public networks) of bootstrapping new services by tunneling
and gateways, which are replaced by more efficient and
easier-to-maintain setups once the new service has attracted sufficient
demand.

Keith

---

From: Terry Gray <[email-masked]>
Date: Thu, 5 Jul 2007 15:36:08 -0700 (Pacific Daylight Time)

We recently sent a team to Africa to better understand the 
connectivity challenges our researchers over there were facing.
Result?  We will soon be deploying our first-ever central VPN service 
on port 80/443 --because those are the only ports you can count on.
In other words, we're going to deploy a VPN service not to *increase*
anyone's security, but to tunnel *around* other people's security 
measures.

-teg

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 6 Jul 2007 12:07:32 +0200

Hence the part in my previous message about dynamically obtaining  
real IPv4 connectivity tunneled over IPv6 when non-simple  
applications need to talk to the IPv4 world.

I understand there is a moratorium on new IPv4-IPv6 transition  
techniques in effect. I'm not familiar with the precise reasons for  
that (I assume it's the huge number of such mechanisms that was being  
proposed) but now that we have a better picture of the obstacles that  
block the transition from happening, I think it's time to revisit  
this and come up with a comprehensive set of transition tools that  
together, address the full range of user needs rather than one here  
and one there.

In my opinion, dual stack has largely served its purpose here and we  
should put that on the back burner and start thinking about going  
IPv6-only in parts of the network, because dual stack by definition  
means adding complexity while it doesn't provide any benefits at this  
time. While IPv6-only has its problems, it does make building a  
network simpler. See

http://arstechnica.com/news.ars/post/20070704-the-declaration-of-ipv6- 
independence.html

But I'll take that up on v6ops.

> And from an
> NATs yet.

Well, an iceberg looks very differently depending on whether you look  
at it above water or below. The problem with NAT is like almost all  
persisting problems: the bad consequences aren't felt in the place  
where they're created.

---

From: Keith Moore <[email-masked]>
Date: Fri, 06 Jul 2007 11:34:25 -0400

> Hence the part in my previous message about dynamically obtaining real
> IPv4 connectivity tunneled over IPv6 when non-simple applications need
> to talk to the IPv4 world.
yes, I like that approach.  and fwiw, I don't think there should be a
moratorium against IETF working on it.

Keith

---

From: Douglas Otis <[email-masked]>
Date: Fri, 6 Jul 2007 11:53:16 -0700

On Jul 6, 2007, at 3:07 AM, Iljitsch van Beijnum wrote:

>> And from an architectural perspective, address translation is  
>> clearly a dead end. One of the reasons we argue against NATs is  
>> not that there aren't other major problems, it's that people  
>> haven't managed to get the message on NATs yet.
>
> Well, an iceberg looks very differently depending on whether you  
> look at it above water or below. The problem with NAT is like  
> almost all persisting problems: the bad consequences aren't felt in  
> the place where they're created.

It should be abundantly clear, being "Internet robust" is not a  
requirement set by the marketplace.  People want their multiplayer  
games and conferencing programs to "just work"!  A transition to full  
IPv6 will be perilous, as it is _not_ possible to drop IPv4 support  
in most environments.

Unfortunately, the NAT problem also represents a business  
opportunity.  This is true whether or not the solutions are condoned  
by a standards body.  In the case of IPv6, Teredo UDP IPv4 tunneling,  
Teredo servers, and PNRP (a name service to navigate Teredo  
topologies) represents an immediate solution.  A solution that  
introduces _more_ translations.

The ideals of end-to-end assume the "end" is "Internet robust."  With  
Teredo and PNRP, external services play a significant role.  Will the  
"end", in conjunction with extremely complex topology ever become  
"Internet robust"?

How will SMTP servers vet sources of inbound messages within an IPv6  
environment?  Virtually every grain of sand can obtain a "new" IPv6  
address.  An IPv6 address may traverse any number of translation  
points as well.

This complex topology spells the end of SMTP in its current form.   
Perhaps SMTP could depend upon SMTP Client names or change into a  
type of URI based notification process, where messages are held by an  
HTTP server.  The URI of the HTTP server might then replace reliance  
upon SMTP Client IP address reputation.  SMTP represents just one  
protocol heavily dependent upon IPv4.

As IPv4 becomes constrained, IPv4 based access control improves.   
Fully adopting IPv6 introduces another problem, IPv6 address access  
controls.

-Doug

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Jul 2007 16:52:43 -0400

--On Friday, 06 July, 2007 11:53 -0700 Douglas Otis
<[email-masked]> wrote:

>... 
> How will SMTP servers vet sources of inbound messages within
> an IPv6 environment?  Virtually every grain of sand can obtain
> a "new" IPv6 address.  An IPv6 address may traverse any number
> of translation points as well.
> 
> This complex topology spells the end of SMTP in its current
> form.  Perhaps SMTP could depend upon SMTP Client names or
> change into a type of URI based notification process, where
> messages are held by an HTTP server.  The URI of the HTTP
> server might then replace reliance upon SMTP Client IP address
> reputation.  SMTP represents just one protocol heavily
> dependent upon IPv4.

Doug, I think you are conflating two problems.  There is running
code (and extensive history) to demonstrate your conclusion is
not correct; the other issue may indicate that some of the
things that are now under development in the IETF are
wrong-headed and that they need to be rethought --now or later.

First, SMTP was designed to work in a multiple-network
environment, with gateways and relays patching over differences
far more significant than anything related to the different
between  IPv4 and IPv6.  Sometimes it underwent smaller or
larger transformations in those other network-transport
environments (e.g., using much more batch-oriented envelope
structures).  But anyone old enough to have seen a message move
from EARN to the Internet and possibly then back to BITNET or
into FidoNet or UUCP-based mail has rather strong empirical
evidence that a mere change of network protocols doesn't do much
to SMTP.   It is perhaps worth remembering that RFC 821 contains
a good deal of text, some appendices, and miscellaneous dancing
around the topic of SMTP over non-TCP services.

On the other hand, any authentication, authorization, or
validation technique that depends either specifically on IPv4
addresses or on some sort of end-to-end connection between the
final delivery MTA (or MUA after it) and Submission MTA (or
earlier) is going to be in a certain amount of trouble: from
IPv6, from long relay chains, from long-delay networks, and so
on.  Obviously some of the proposed mechanisms in that class are
much more sensitive to network variations (or, in the worst
cases, any situation in which there is not a single connection
between the MSA and the delivery server) and maybe the IETF
should be looking harder at those characteristics before
publishing or standardizing them.  

But the oldest sender-authentication and message integrity
mechanisms of all don't depend on such endpoint connections over
a single network technology: I, and I imagine many others, have
had mailboxes on and off for 20-odd years that will not accept
any traffic that does not arrive with a digital signature over
the content that can be verified by software in the delivery
(receiving) system and with requirements on the signed content,
such as sequence numbers or time stamps, to prevent replay
attacks.  Such approaches either require a strong PKI or secure
out-of-band transmission of secret keys, don't scale, or both,
but those aren't SMTP problems.

     john

---

From: Keith Moore <[email-masked]>
Date: Fri, 06 Jul 2007 19:17:43 -0400

> environment? 
I don't know, but except for very limited corner cases, trying to use a
source address to vet the source in an IPv4 environment is foolish and
error-prone.  It is no less foolish and error-prone in IPv6, but that's
not the fault of IPv6.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Fri, 06 Jul 2007 16:41:05 -0700

John C Klensin wrote:
>> form.  
...
> not correct; 

As you note, the world used to be rather more complicated and it worked fine.

Besides the integrate service, using heterogeneous email standards, that you 
cite, folks might want to take at another historical reference:

    <http://www.isi.edu/in-notes/rfc1775.txt>.

That the current world is pressing for end-to-end authentication is not a new 
requirement.  The challenge is present whether we have v4/v6 or just one IP, 
to serve us all.

But, then, email is multi-hop -- contrary to some people's model -- so that's 
why we try to design mechanisms that work... multi-hop.

> addresses or on some sort of end-to-end connection between the

This is only one of the examples of the fundamental weakness of any scheme 
based on Path Registration -- that is, authentication based on a topology tag, 
such as an IP Address.  Path Registration works for single-hop scenarios, 
albeit even then with significant limitations.

Specifically: tying topology information to messaging means that it cannot 
work for multi-hop scenarios.

d/

ps.  We can have some fun debating the meaning of "multi-hop" since travel 
through a sequence of IP routers is multi-hop, even though the TCP connection 
is "direct".  Similarly, an SMTP or SUBMISSION session that goes through a 
proxy might entail multiple TCP connections, but the mail-level view is that, 
again, the interaction is direct.

-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Fri, 6 Jul 2007 17:07:00 -0700

On Jul 6, 2007, at 1:52 PM, John C Klensin wrote:

>> How will SMTP servers vet sources of inbound messages within an  
>> IPv6 environment?  Virtually every grain of sand can obtain a  
>> "new" IPv6 address.  An IPv6 address may traverse any number of  
>> translation points as well.
>>
>> type of URI based notification process, where messages are held by  
>> an HTTP server.  The URI of the HTTP server might then replace  
>> reliance upon SMTP Client IP address reputation.  SMTP represents  
>> just one protocol heavily dependent upon IPv4.
>
> code (and extensive history) to demonstrate your conclusion is not  
> correct; the other issue may indicate that some of the things that  
> are now under development in the IETF are wrong-headed and that  
> they need to be rethought --now or later.

It is more a matter of remaining relevant.  If not now, then later  
matters even less.

> First, SMTP was designed to work in a multiple-network environment,  
> with gateways and relays patching over differences far more  
> significant than anything related to the different between  IPv4  
> and IPv6.  Sometimes it underwent smaller or larger transformations  
> in those other network-transport environments (e.g., using much  
> more batch-oriented envelope structures).  But anyone old enough to  
> have seen a message move from EARN to the Internet and possibly  
> then back to BITNET or into FidoNet or UUCP-based mail has rather  
> strong empirical evidence that a mere change of network protocols  
> doesn't do much to SMTP.   It is perhaps worth remembering that RFC  
> 821 contains a good deal of text, some appendices, and  
> miscellaneous dancing around the topic of SMTP over non-TCP services.

You are right about SMTP "working" across topologies.  I setup UUCP  
for offices back when dedicated business lines were considered too  
expensive.  I set up older messaging schemes for my customers while  
conducting a peripheral design business.  This business demanded  
timely exchanges of schematics, wire-lists, PCB photo-plots, test- 
vectors, and firmware.  When first learning of the Internet, it was  
costing more than $10 per one page fax to Japan.  It sounded as if  
the Internet was some sneaky method to "steal" expensive telco services.

Low cost Internet services together with today's level of abuse has  
lead to unintended DDoS attacks.  Defending against this unintended  
attack depends upon IP address history.  When this history proves  
ineffectively at refusing traffic from previously noted bad actors,  
SMTP no longer "works".  It has been an ongoing battle to ensure bad  
actors are unable to exploit easily obtained IP addresses.  This  
includes addresses used by dial-up accounts, compromised residential  
systems, and even ISPs not enforcing adequate AUPs.  Compromised  
residential systems makes discerning the last category difficult, and  
perhaps soon abandoned as yet another casualty of faltering security.

> On the other hand, any authentication, authorization, or validation  
> technique that depends either specifically on IPv4 addresses or on  
> some sort of end-to-end connection between the final delivery MTA  
> (or MUA after it) and Submission MTA (or earlier) is going to be in  
> a certain amount of trouble: from IPv6, from long relay chains,  
> from long-delay networks, and so on.  Obviously some of the  
> proposed mechanisms in that class are much more sensitive to  
> network variations (or, in the worst cases, any situation in which  
> there is not a single connection between the MSA and the delivery  
> server) and maybe the IETF should be looking harder at those  
> characteristics before publishing or standardizing them.

Depending upon DNS to migrate protocol behavior is one concern.   
Wildcard records in DNS can increase the amplifications of some  
"intentional" DDoS attacks.  To support SMTP, some servers will issue  
a long series of "scripted" DNS transactions which might have been  
dictated by bad actors (as if the goal was to taint and/or kill  
DNS).  At least PNRP does not depend upon DNS.  What will the IETF  
offer as an alternative to this proprietary name resolution protocol?

> mechanisms of all don't depend on such endpoint connections over a  
> single network technology: I, and I imagine many others, have had  
> mailboxes on and off for 20-odd years that will not accept any  
> traffic that does not arrive with a digital signature over the  
> content that can be verified by software in the delivery  
> attacks.  Such approaches either require a strong PKI or secure out- 
> of-band transmission of secret keys, don't scale, or both, but  
> those aren't SMTP problems.

An inability to validate an SMTP client name, or the remaining  
provisions permitting A record server discovery makes SMTP much  
harder to defend within complex topologies.  These are general  
weaknesses created by SMTP that are unrelated to cryptographic  
strategies.

If SMTP were used to only exchange URIs (as a public version of a  
BURL extension), then there would be no need for SMTP  
authentication.  HTTP certificates scale and are already cached by  
the OS.  Atlas, proprietary interfaces within HTTP are also nearly  
impossible to defend.  Another area where standardization has failed.

The cryptographic strategy used by DKIM does not offer a means to  
correlate signing domains with SMTP client domains transmitting to a  
public server.  An inability of domains to authorize signing domains  
eliminates what might have been a reasonable approach for coping with  
possible replay abuse.  In addition, transparent authorizations of  
signing domains using CNAMES or DNS sub-delegation makes DNS less  
robust by increasing server dependence.  Importantly, transparent  
authorization will not provide any anti-replay abuse strategy.  DKIM  
may then devolve into a key-per-user as a feckless anti-replay  
strategy.  Excessive use of short lived and large cryptographic key  
RRs may also provide another cause for DNS to falter.  Never mind the  
follow-on domain transversal or DNS wildcard policy schemes.

DNS has several weakness by today's standards, which do not lend  
themselves to easy or rapid correction.  What happens when SMTP's  
awkward defensive strategies result in a loss of confidence in a  
faltering DNS?

-Doug

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 7 Jul 2007 09:45:19 +0900 (JST)

> error-prone.  It is no less foolish and error-prone in IPv6, but that's

	from my experience
	- very few SMTPv4 servers look at PTR/A record matching.  i'm not sure
	  how i can configure sendmail/procmail to do this.
	- i never found any RBL-style blacklist for IPv6.
	- spammers DO use SMTPv6.  by chance or by intention?  not sure.
	- more and more ISP SMTPv4 servers do filter SMTPv4 from outside of
	  its network, to prevent the abuse by spammers.
	- more and more ISP infrastructure practices OP25B for IPv4.

	i'm not too sure about the latter two in IPv6.  maybe we should ask
	NTT and IIJ email ops division about this.

itojun

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sat, 07 Jul 2007 15:54:31 +0900

>	- more and more ISP infrastructure practices OP25B for IPv4.

	OP25B = Outbound Port 25 Blocking.  it disallows ISP customers to run
	SMTP server, or use SMTP server outside of the ISP network.
	maybe it is japanese-local acronym, google shows me japanese 
	pages only.

itojun

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sat, 07 Jul 2007 15:54:31 +0900

itojun

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 7 Jul 2007 20:19:40 +0200

On 6-jul-2007, at 20:53, Douglas Otis wrote:

> IPv6 environment?  Virtually every grain of sand can obtain a "new"  
> IPv6 address.

Simple: look at prefixes rather than individual addresses. If  
2002::2002 is a spammer, then you may want to assume that 2002::2003,  
2002::2004 etc are also spammers. With IPv6, the "CIDR distance"  
between nodes under different administration should be considerably  
larger than with IPv4, where you'll often see systems belonging to  
different people on consecutive addresses.

> An IPv6 address may traverse any number of translation points as well.

Huh? What are you talking about?

> This complex topology spells the end of SMTP in its current form.

And that's a bad thing? It's the fundamental lack of, well,  
everything, in SMTP that allows all this spam that we're suffering  
from these days and makes it impossible to get rid of things like the  
base64 encoding overhead.

Build a better mousetrap rather than complain that the mice don't  
like the cheese.

---

From: Douglas Otis <[email-masked]>
Date: Sat, 7 Jul 2007 16:05:58 -0700

On Jul 7, 2007, at 11:19 AM, Iljitsch van Beijnum wrote:

>> "new" IPv6 address.
> 2002::2002 is a spammer, then you may want to assume that  
> 2002::2003, 2002::2004 etc are also spammers. With IPv6, the "CIDR  
> distance" between nodes under different administration should be  
> considerably larger than with IPv4, where you'll often see systems  
> belonging to different people on consecutive addresses.

Recommending CIDR blocking will not win accolades.  This is one of  
the evils most want to avoid.  The dynamics of IPv6 addressing is  
part of the problem.  IPv6 might utilize a translation of some IPv4  
address, perhaps of a session crossing through the IPv4 address space  
into IPv6 address space via gateways.  These translations will likely  
be dynamically assigned.  Just the ease of being able to obtain a new  
IPv6 address represents a problem although this is also touted as a  
feature.  IPv6 address vetting is unlikely to effectively track bad  
actors, nor will reverse DNS be all that useful.

> Huh? What are you talking about?

There will be many ways to bridge between the IPv4 and IPv6 address  
space.

> And that's a bad thing?

Probably not.  However, the IETF might want to consider what is  
needed to transition into something more robust once IPv6 space is  
allowed to send email.  Difficult to obtain non-volatile references  
are essential for tracking abuse history.  The difficulty is with the  
difficult-to-obtain reference.

PNRP depends upon groups.  Groups work in a fashion similar to that  
of a mailing list.  This suggests there could be intermediaries  
offering references.  Evidence of abuse should be limited to the  
transmitting domain and not the individual.  Dealing with abuse  
should be internal to the domain.

Limiting accountability to the domain is a major sticking point  
within the current email infrastructure.  Those transmitting messages  
into public servers wish to avoid accountability.  However,  
accountability simply does not scale down at an individual to  
individual level.  There must be some form of collective  
accountability established.

One way this could be accomplished would be to create a message that  
is nothing more than a URI.  This could be done in a manner similar  
to BURL.  The URI could be constructed of a double hash of a time- 
stamp, source identifier, and content.  Message storage and retrieval  
could even utilize object storage.

The "group" would be the web URL where the sender stored the  
individuals' messages.  Recipient access could depend upon either the  
obscurity of the double hash or handled by a scheme similar to  
OpenID.  This approach should scale, and yet ensure references are  
obtained from those offering an HTTP message access service.  This  
would allow combining both SMTP and HTTP into a unified URL  
reputation vetting system independent of any underlying IP address.

> It's the fundamental lack of, well, everything, in SMTP that allows  
> all this spam that we're suffering from these days and makes it  
> impossible to get rid of things like the base64 encoding overhead.

The transition will likely need to be evolutionary and not  
revolutionary.  MUAs could be modified to handle either form of  
messaging.  At some point, those still using the old methods will be  
too few to matter.

> Build a better mousetrap rather than complain that the mice don't  

Agreed.  But is this something the IETF will even consider?  Are  
there too many vested in the old mousetrap?

-Doug

---

From: Mark Andrews <[email-masked]>
Date: Sun, 08 Jul 2007 10:15:29 +1000

> different people on consecutive addresses.

	You will still see consective addresses with IPv6.  Until
	you put a *dedicated* router at the end of the DSL line or
	on the cable modem etc.  there will still be lots of addresses
	handed out where the next address is managed by someone
	else.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 7 Jul 2007 20:41:33 -0500

Thus spake "Mark Andrews" <[email-masked]>
> handed out where the next address is managed by someone

That's not necessary, though it's the ideal scenario once v4 is dead in a 
decade or two and it's feasible for consumer-grade ISPs to reorganize their 
L2 networks.

In the meantime, what I've been expecting to see is that ISPs would use a 
/64 for the "shared" access subnet and then the CPE devices (a stateful 
firewall) would use DHCP PD to get a /64 for each customer's site.  This is 
entirely compatible with using PA v4 space on the access subnet and having 
the CPE NAT to RFC1918 space (typically 192.168.1/24).

Thanks to RFC 3041, you may never see two connections using the same IPv6 
address and have to block a /64 at minimum for blacklists to have any 
effect.  Fortunately, that's entirely compatible with most deployment 
scenarios, as each customer will be on their own /64 (or shorter).

S

Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov

---

From: "Stephen Sprunk" <[email-masked]>
Date: Fri, 13 Jul 2007 11:33:25 -0500

Thus spake "Keith Moore" <[email-masked]>
> NAT-PT really needs to be wiped off the face of the earth.  It
> provides all of the disadvantages of IPv4+NAT with all of the
> transition costs of IPv6.

Indeed it does.  However, it has significant benefits as well:

1) It eliminates the need for all sites to dual-stack their hosts between 
the time v4 exhaustion hits and the last v4-only site disappears, which 
could be a decade or more.  There's also no sign this will actually happen 
in time without NAT-PT, leading to fragmentation of the Internet into 
v4-only and v6-only parts that can't talk to each other.

2) It may eliminate the need to dual-stack entirely; NAT-PT allows a site to 
flash cut from v4 to v6 without a long transition period.  This would 
provide substantial cost savings to leaf site operators, many of whom are 
not deploying v6 today due to the perceived cost of dual-stacking.  We 
remember the days of having to manage IP(v4), IPX, AppleTalk, DECnet, etc. 
all on the same network and aren't looking forward to returning to that 
mess.

3) Deployment of NAT-PT would instantly provide hundreds of millions of 
hosts that _appeared_ to be dual-stacked, accelerating the deployment of v6 
and bringing forward the day we can turn off v4 in the DFZ (even if 
individual leaf sites are still v4-only internally).

> If there is ever any significant penetration of NAT-PT, then the

In the beginning stages, yes.  However, unlike v4 NAT, if one has a problem 
with NAT-PT and how it affects applications, all one has to do is deploy v6 
and they go away.  Well, at least those that aren't actually caused by 
having a stateful firewall...

Besides, nearly everyone is behind a v4 NAT today, so things aren't going to 
get any worse for v4 traffic, and they'll gradually improve for v6 traffic 
as folks deploy it and start to bypass their NAT-PT devices.

All of this "applications for v6 aren't designed to cope with NAT" stuff is 
bunk.  Applications are designed to use both v4 and v6 because there's no 
market for v6-only apps.  Apps have already paid the cost of dealing with 
NAT (if it affects them) and so will future apps until we can manage to drop 
v4 entirely.  If NAT-PT allows us to drop v4 sooner, it's that much sooner 
app developers can stop paying that cost, and that's good for everyone.

S

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 14 Jul 2007 02:08:55 +0900 (JST)

> Indeed it does.  However, it has significant benefits as well:
(snip)

	cannot agree more.  i do not care if it is based on TCP/UDP relaying
	(per session) or NAT-PT (per packet), but IPv6-to-IPv4 translators
	have its own benefits.  and of course drawbacks, but the drawback
	is much smaller than conventional IPv4-to-IPv4 NAT as we have an escape
	plan (use native IPv6).

itojun

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Jul 2007 13:10:03 -0400

Stephen Sprunk wrote:
> [arguments about NAT-PT avoiding the need to dual-stack hosts deleted]
Dual-stacking hosts is a non-problem.  For the majority of deployed
hosts, it is already done.  

Adapting existing networks to IPv6 is somewhat painful, but most of the
deployed hardware supports it.

On the other hand, adapting existing security policies, traffic filters,
network intrusion detection systems, explicit and interception proxies
is much harder.  In some cases the products or upgrades don't even exist
for IPv6, and when they do, they're not mature.
> In the beginning stages, yes.  However, unlike v4 NAT, if one has a
> problem with NAT-PT and how it affects applications, all one has to do
> is deploy v6 and they go away. 
That's like saying that if you are a IPv4 software developer and your
applications won't work at your customers' sites because they have NATs,
all you have to do is get rid of your own NAT and your customers'
problems will go away.

It simply doesn't work that way.  NATs create problems even for people
who don't use them.
> Besides, nearly everyone is behind a v4 NAT today, so things aren't
> going to get any worse for v4 traffic, and they'll gradually improve
> for v6 traffic as folks deploy it and start to bypass their NAT-PT
> devices.
>
> All of this "applications for v6 aren't designed to cope with NAT"
> stuff is bunk.  Applications are designed to use both v4 and v6
> because there's no market for v6-only apps.  Apps have already paid
> the cost of dealing with NAT (if it affects them) and so will future
> apps until we can manage to drop v4 entirely.  If NAT-PT allows us to
> drop v4 sooner, it's that much sooner app developers can stop paying
> that cost, and that's good for everyone.
All of these gross generalizations about applications are bunk.   The
patterns of interaction between nodes of an application, and the effect
that NATs have on them, vary widely from one application to another.  
Any generalization of the form "applications do X" is dubious on its face.

There are basically two incentives to support IPv6: one is more
addresses, the other is a better behaved network that is capable of
supporting a wider range of applications at lower cost.  If NAT-PT is
widely deployed, the second incentive is removed.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Jul 2007 13:19:16 -0400

> 	is much smaller than conventional IPv4-to-IPv4 NAT as we have an escape

translators do have benefits, and can be mostly harmless with applied
judiciously.  the problems result from imposing translators in the
signal path to/from a significant number of hosts that are running
arbitrary applications. 

NAT-PT style translators can be just fine when used with a small number
of specific hosts for which it is known that the applications on those
hosts won't be harmed by the interposition of NAT-PT.  though frankly,
most users aren't capable of doing such analysis - just like most users
don't understand the harm that NAT does.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 14 Jul 2007 02:24:56 +0900 (JST)

> don't understand the harm that NAT does.

	how many applications do you have that does not run across NATs?

	how many of them have hardcoded 32bit address field in the payload?

	in fact, as posted a couple of weeks ago i got an IPv6-only wireless
	network which works just fine for me.  the only applications that does
	not go through it are:
	- Skype (MacOS X)
	- Software Update (MacOS X)
	- .Mac Sync (MacOS X)
	- NFS (any OS)
	caveat: i'm not a heavy user of multi-media apps nor BitTorrent.

itojun

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 13 Jul 2007 19:27:20 +0200

> 	is much smaller than conventional IPv4-to-IPv4 NAT as we have an  

It seems like the discussion I was trying to start in v6ops is  
happening here instead... http://psg.com/lists/v6ops/v6ops.2007/ 
msg00467.html

I don't think NAT-PT or transport relay are the best choices to allow  
IPv6 hosts to talk to IPv4 hosts, because they both require the  
insertion of boxes with very non-standard behavior in the network and  
a DNS ALG to get the packets to those boxes. Using existing proxies  
is easier, because they don't create DNS pollution or strange boxes,  
they're simply applications running on a server, like so many other  
applications. The fact that proxies are already widely deployed  
doesn't hurt, of course.

(NAT-PT/transport relay require the host to do DNS lookups over IPv6  
or have IPv4 connectivity for the DNS lookups, while proxying is even  
possible if the host doesn't have access to the DNS. Example: set up  
proxying towards an [IPv6 address] in IE7 on Win XP, which can't do  
DNS over IPv6 transport.)

But we can't stop here, we need to provide a way to handle  
applications that have more extensive needs than those that can be  
met by a proxy as well, or the effect will be NAT/ALG stuff in IPv6.  
In my opinion, the easiest way to do this is to tunnel IPv4 over IPv6  
on demand. I gather the softwires wg is working on that.

So if we add some glue in the form of an API or logic that knows when  
to switch from proxying to real tunneled IPv4 connectivity and  
discovery / automatic setup we're in good shape and people can start  
removing IPv4 from their networks except at the borders where the  
translation happens.

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Jul 2007 13:38:40 -0400

> 	how many applications do you have that does not run across NATs?
that I personally use?  I'm guessing about a half-dozen, though I don't
use them all everyday.  some other apps work across NAT but with
degraded functionality.

at my last job, where we worked on distributed computing systems? 
several more than that.
> 	how many of them have hardcoded 32bit address field in the payload?
hard to say.  I tried to promote IPv6-awareness at my last job and to
get developers to stop assuming that an address was 32 bits. 

but the bigger problem isn't the hard-coded address size - it's the
conflict between the application writer's desire that the network
provide complete connectivity (imagine having a network that actually
provided best-effort packet delivery!), and the various things that
exist to split the network up into realms with arbitrary constraints on
how traffic can be routed between those realms.  having multiple address
realms of any kind - be they private address realms behind NATs, or
IPv4/IPv6, or whatever - basically forces apps to implement their own
routing, and sometimes, their own addressing.  and requiring apps to
have their own routing is tantamount to requiring them to have their own
infrastructure that is rooted in the public Internet (probably on port
80) where all nodes can presumably reach them.

it's much simpler to write a distributed app that is either entirely
IPv4 or entirely IPv6 than to write one that supports both.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 14 Jul 2007 02:46:46 +0900 (JST)

> use them all everyday.  some other apps work across NAT but with

	okay.  if you could name them we can try to convince people who are
	responsible.

> at my last job, where we worked on distributed computing systems? 

	we kame are guilty for almost every application IPv6 support, including
	Python, Apache, Ruby, Postfix (wietse rewrote the whole thing), all tools
	on *BSD, BSD libc, whatever.  honestly noone can beat us on this topic:-P

> 80) where all nodes can presumably reach them.

	so, which is your real-world protocol which has the above problem?  or
	is it a theoretical debate?  "code then spec".

	one way is to have a session-layer protocol (finally!).
	or, you can switch from TCP to SCTP.

	i have been trying to persuade openssh coders to have functionality
	to re-connect ssh session even when TCP session go down.  if you tunnel
	everything over ssh, you won.

> IPv4 or entirely IPv6 than to write one that supports both.

	you have to.  you cannot be that lazy.  or .Net framework (Windows) or
	CFNetwork (MacOS X) can handle it for you inside the library.
	http://www.amazon.com/exec/obidos/ASIN/(A1555583180(B

itojun

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 13 Jul 2007 10:57:22 -0700

I think we need to look beyond whether NAT is evil (or not) and whether NATPT is the solution (or not) and look to see how we might manage a transition to IPv6 in a way that is not predicated on holding ISP customers hostage.

People have been there and done that, anyone remember when the anti-spam blacklists started talking about 'collateral damage' with great glee? Within a very short time a very large number of email admins hated the self appointed maintainers of the blacklists more than the spammers.

We have three Internets: IPV4, IPv4+NAT and IPv6.

Clearly the IPv4 Internet is going to run out of addresses. That does not mean that IPv4 will go away however. As far as the ISPs are concerned IPv4+NAT works just fine for residential connections. 

What we need is a transition strategy that is more effective than dual stack. IPv6 is not going to work as a solution to the IPv4 address space crunch if every IPv6 Internet user has to have an IPv4 address as well.

This strongly suggests to me that during the transition, a period I expect to last until 2025, we will want the standard Internet allocation to be a /64 of IPv6 plus a share in a pool of IPv4 addreses behind a NAT.

What I would like to get to is a situation where a consumer can 1) purchase Internet connectivity as a commodity with a well defined SLA that assures them that the connection will work for the purposes they wish to use it 2) obtain a report from their Internet gateway device(s) that tells them whether the SLA is being met or not. 

>From the point of view of the consumer all that matters is that their client applications and their peer-2-peer applications work. The typical consumer does not host servers at their home and we want the sophisticated consumer to move to IPv6.

Most application protocols work just fine behind NAT. FTP works with an ugly work-around. The main protocol that breaks down is SIP. I am mighty unimpressed by the fact that when I plug the VOIP connector made by vendor X into the wirless/NAT box made by vendor X that I have to muck about entering port forwarding controls by hand. And even less impressed by the fact that a good 50% of the anti-NAT sentiment on this list comes from employees of vendor X.

STUN does not appear to me to be an architecturally principled approach, it is a work around.

The way to fix this situation in my view is to make the NAT box SIP aware by building a SIP proxy capability into the NAT box. The designers of NAT boxes go to great efforts to try to work around applications. Leave approaches such as STUN to the case where you are dealing with a legacy box.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 13 Jul 2007 11:06:29 -0700

Perhaps one of the Cisco employees could explain whether the change in the IETF status will cause this product to go to end of life or end of sales?
 
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/ipv6_c/sa_natpt.htm
 
If the answer is 'no' then this entire line of argument is bunk. The Internet is going to be built by real engineers solving real engineering problems with running code. 

________________________________

From: Keith Moore [mailto:[email-masked]]
Sent: Fri 13/07/2007 1:10 PM
To: Stephen Sprunk
Cc: [email-masked]; Paul Hoffman
Subject: Re: chicago IETF IPv6 connectivity

Keith

---

From: shogunx <[email-masked]>
Date: Fri, 13 Jul 2007 14:06:16 -0400 (EDT)

> The way to fix this situation in my view is to make the NAT box SIP
> aware by building a SIP proxy capability into the NAT box. The designers
> of NAT boxes go to great efforts to try to work around applications.
> Leave approaches such as STUN to the case where you are dealing with a
> legacy box.
>

My SIP ATA sits behind a iptables based NAT, and I have never had a
problem with it.  No STUN either.  Symmetric IP Masquerading does the
trick.  Then again, it is not a commercial NAT device, just a
function of the iptables firewalling suite in the linux kernel and
associated userland tools.

Enjoy,
Scott

sleekfreak pirate broadcast
http://sleekfreak.ath.cx:81/

---

From: "Stephen Sprunk" <[email-masked]>
Date: Fri, 13 Jul 2007 13:48:13 -0500

> Dual-stacking hosts is a non-problem.  For the majority of
> deployed hosts, it is already done.

That depends on the definition you're using.  Many hosts are v6-capable, 
though I'd still debate whether it's the majority.  Very, very few of those 
hosts have working v6 connectivity because there's some device(s) or 
provider(s) between the host and the DFZ that are v4-only.

Even with Vista supporting v6 by default, the vast majority of Vista 
machines are behind NAT boxes that only support v4.  In the case of 
enterprise networks, the internal network is also v4 only, limited by one or 
more of hardware, software, and motivation.  Many ISPs, particularly 
consumer ones, don't offer v6 service at all, though that's improving daily 
and one can work around it with 6to4.

Dual-stacking a network, even a home network, is _not_ a non-problem.

> Adapting existing networks to IPv6 is somewhat painful, but
> most of the deployed hardware supports it.

It's humans and software, not hardware, that is generally the problem 
getting v6 deployed.

> On the other hand, adapting existing security policies, traffic
> filters, network intrusion detection systems, explicit and
> interception proxies is much harder.  In some cases the
> products or upgrades don't even exist for IPv6, and when they
> do, they're not mature.

So put the NAT-PT device on the outside of those security boxes.  Presto, 
instant access from your v4 network to every v6-only host out there and vice 
versa, without any compromise of security.  There is a compromise of 
functionality, but it's no worse than what you've got for v4 connectivity 
because you're behind a NAT for that too...

There's a lot of focus on NAT-PT for v6 sites to access remote v4-only 
sites; I'm focusing on the case of v4-only sites using NAT-PT to access 
remote v6-only sites.  That is the case that's going to go critical in 2-4 
years when exhaustion hits.  After that, folks can deploy real v6 internally 
(or even flash cut) when they see that a significant fraction of their 
outbound traffic is v6 -- or when the slower vendors finally get around to 
fixing their products.

>>> If there is ever any significant penetration of NAT-PT, then
>>> the pseudo-IPv6 network will not be able to support any
>>> more kinds of applications than the NATted IPv4 does today.
>>
>> In the beginning stages, yes.  However, unlike v4 NAT, if one
>> has a problem with NAT-PT and how it affects applications,
>> all one has to do is deploy v6 and they go away.
>
> That's like saying that if you are a IPv4 software developer and
> your applications won't work at your customers' sites because
> they have NATs, all you have to do is get rid of your own NAT
> and your customers' problems will go away.

That's not the same thing at all.

> It simply doesn't work that way.  NATs create problems even
> for people who don't use them.
>
>> Besides, nearly everyone is behind a v4 NAT today, so things
>> aren't going to get any worse for v4 traffic, and they'll gradually
>> improve for v6 traffic as folks deploy it and start to bypass
>> their NAT-PT devices.

I must have ESP (and not the IPsec kind), because I already responded to 
that point...

> There are basically two incentives to support IPv6: one is
> more addresses, the other is a better behaved network that
> is capable of supporting a wider range of applications at
> lower cost.  If NAT-PT is widely deployed, the second
> incentive is removed.

No, the second incentive remains.  Fully deploying v6 is still a good idea 
because it removes the problems inherent to NAT-PT, which I've already 
acknowledged.  However, the alternative is worse.  If you're still stuck on 
v4 because your vendors and/or management won't allow you to deploy v6, and 
v6-only sites start appearing, you can't contact those folks _at all_. 
Connectivity to those sites via NAT is better than no connectivity at all. 
Do _you_ want to be the first v6-only site on the Internet, unable to talk 
to 99% of other hosts out there?

And, as Phillip says, it's a moot point because vendors are shipping NAT-PT 
anyways.  The IETF can deprecate whatever it wants, but the market will 
provide what is needed.  The IETF hasn't been very successful at eliminating 
v4 NAT either...

S

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Jul 2007 15:27:37 -0400

> Most application protocols work just fine behind NAT. FTP works with
> an ugly work-around. The main protocol that breaks down is SIP.
>

there are a couple of problems with this analysis:

one is that it considers only application protocols that are in
widespread use.  there are lots of applications that are used by limited
communities that are nevertheless important.  and of course, since NATs
are so pervasive, most of the applications that are in widespread use
have been made to work with NAT (often at tremendous expense, and
reduced reliability).

another problem is that it only considers current applications.  a big
part of the problem with NAT is that it inhibits the
development/deployment of useful new applications.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Jul 2007 15:44:22 -0400

> 	okay.  if you could name them we can try to convince people who are
the people responsible for polluting the network with NATs? it's too
late to punish them, I fear :)
> 	on *BSD, BSD libc, whatever.  honestly noone can beat us on this topic:-P
and the rest of us are very appreciative! of course, not all of the
applications that people use are those that are shipped with *BSD. and
while it's quite helpful if programming languages support IPv6, that
doesn't mean that the programs written in those languages will
automatically work with IPv6.
> 	is it a theoretical debate?  "code then spec".
no, it's not a theoretical debate. I worked with a number of distributed
systems: PVM, some MPI implementations, and one of my own design that
didn't become so popular. There are a lot of applications layered on top
of one or the other of these. But unless you're into high-performance
computing you probably aren't aware of them.
> 	or, you can switch from TCP to SCTP.
for several reasons, SCTP is not a drop-in replacement for TCP. (but I'd
love to see further development and standardization of multipath TCP -
that seems like a very promising avenue)
> 	everything over ssh, you won.
sigh. yes that would be valuable functionality, but somehow I don't
think that the answer to every problem imposed by shortsighted hacks in
the network is to push things down another layer. and this kind of
solution only solves the problem for two-node applications.
> 	you have to.  you cannot be that lazy.  
our goal in IETF should be to allow programmers to be that lazy.
separation of function between the host and the network is a Good Thing.
let the hosts exchange packets and the network route them.

the goal is certainly not to keep increasing complexity of the network
and to keep making programmers' jobs more difficult.
> or .Net framework (Windows) or
only if you want your application to be crippled in other ways. (my, you
have a simplistic view of the application world!)

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Jul 2007 15:46:30 -0400

Hallam-Baker, Phillip wrote:
> Perhaps one of the Cisco employees could explain whether the change in
> the IETF status will cause this product to go to end of life or end of
> sales?
>  
> If the answer is 'no' then this entire line of argument is bunk. The
> Internet is going to be built by real engineers solving real
> engineering problems with running code.
either that, or it will be destroyed by people pretending to be
engineers (but failing to use any semblance of engineering discipline),
solving imagined and/or poorly understood problems, with code that runs
amok.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 13 Jul 2007 12:49:24 -0700

Future applications are the easiest to deal with.
 
If we have a proper encapsulation of the network layer the application will run fine on either an IPv6 or an IPv4/NAT network or a transitional IPv6 plus NAT pool of IPv4 addresses. The only thing that the application designer needs to take care of is that they use an appropriately structured API that can handle 32/128 bit address issues. This is no different in principle from what is involved in writing clean 32/64 code.

From: Keith Moore [mailto:[email-masked]]
Sent: Fri 13/07/2007 3:27 PM
To: Hallam-Baker, Phillip
Cc: Stephen Sprunk; Jun-ichiro itojun Hagino; Paul Hoffman; [email-masked]
Subject: Re: IPv4 to IPv6 transition

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Jul 2007 15:59:22 -0400

> That depends on the definition you're using.  Many hosts are
> v6-capable, though I'd still debate whether it's the majority.  Very,
> very few of those hosts have working v6 connectivity because there's
> some device(s) or provider(s) between the host and the DFZ that are
> v4-only.
agreed, but you were talking about hosts.
> It's humans and software, not hardware, that is generally the problem
agreed about humans - mindshare is the hardest thing to overcome.  the
software/hardware question is a distinction without a significant
difference.   if the products (you think) you need to secure your
network aren't shipping, it doesn't matter much whether what you need is
new hardware or a software upgrade.  often, that's just a matter of
packaging.
> So put the NAT-PT device on the outside of those security boxes.  
and then you end up with a crippled network that will impair a lot of
the functionality you would have gained by using IPv6, and one which
pollutes DNS besides. 
> sites; I'm focusing on the case of v4-only sites using NAT-PT to
> access remote v6-only sites.  
that's certainly an important case, but there are better ways than
NAT-PT for v6-only sites to provide services to v4-only users.
> No, the second incentive remains.  Fully deploying v6 is still a good
> idea because it removes the problems inherent to NAT-PT, which I've
> already acknowledged.
yes, but everyone else's NAT-PT boxes still keep you from getting most
of the benefit from your upgrade to full IPv6.
> And, as Phillip says, it's a moot point because vendors are shipping
> NAT-PT anyways.
BS.  that's equivalent to the argument that because everyone else is
evil, we might as well be evil too.

IETF is useless if it doesn't try to describe what will work well in the
long term.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Jul 2007 16:01:01 -0400

Hallam-Baker, Phillip wrote:
> If we have a proper encapsulation of the network layer the application
> will run fine on either an IPv6 or an IPv4/NAT network or a
> transitional IPv6 plus NAT pool of IPv4 addresses. The only thing that
> the application designer needs to take care of is that they use an
> appropriately structured API that can handle 32/128 bit address
> issues. This is no different in principle from what is involved in
> writing clean 32/64 code.
I always find these kinds of statements amusing.

Keith

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Jul 2007 22:08:33 +0200

Hi Phillip,

~Snip~

> Most application protocols work just fine behind NAT.
I agree. I am playing games for a really long time and I rarely had ever 
problems with NATs.
Obviously these companies don't shy away from solution that would be 
classified as "architectural not nice".
Without knowing the NAT traversal details of the different games I play 
I could imagine that they even carry their payloads on top of HTTP, if 
nothing else works. Nasty!

>  FTP works with an ugly work-around. The main protocol that breaks down is SIP.

Not with the work that was done on NAT traversal.

>  I am mighty unimpressed by the fact that when I plug the VOIP connector made by vendor X into the wirless/NAT box made by vendor X that I have to muck about entering port forwarding controls by hand. And even less impressed by the fact that a good 50% of the anti-NAT sentiment on this list comes >from employees of vendor X.
>
I wonder why you think so. What's the problem with STUN?

> The way to fix this situation in my view is to make the NAT box SIP aware by building a SIP proxy capability into the NAT box. The designers of NAT boxes go to great efforts to try to work around a…
I think that's a really horrible solution.

There are good protocols out there to provide legacy NAT traversal. If 
NAT (and firewall vendors) would implement protocols that support NAT 
traversal then the performance issues can also be taken care of.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Jul 2007 22:11:20 +0200

Hi Keith,

Keith Moore wrote:
> communities that are nevertheless important.

Namely?

>   and of course, since NATs
Could you explain the tremendous expense a bit more?

> development/deployment of useful new applications.

As Phillip stated, I don't see the problem with future applications. 
Compare this with the security aspects that are taken care of much more 
than before when developing new applications NAT traversal is just 
another thing to think about as a protocol designer.

Ciao
Hannes

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Jul 2007 16:21:26 -0400

>> communities that are nevertheless important.
that's a silly question.  you wouldn't recognize the names if you saw
them, because they're not in widespread use.
> Could you explain the tremendous expense a bit more?
several kinds of expense: one is due to added implementation complexity
where you have to implement your own addressing and routing scheme
within the application - and this results also in poorer performance and
(usually) degraded reliability because there are more things in the
signal path that can fail.  another kind of expense is that when trying
to set up communication between two or more peers that are all behind
NAT you usually need to have a rendezvous server that is on the public
network that can mediate between the hosts that are NAT-crippled.  it
costs money to provide those servers, especially if you get a lot of
usage.  this tends to mean that the application can no longer be free or
open source, because there has to be a way to pay for those servers. 
this is hugely costly to the user community.
> As Phillip stated, I don't see the problem with future applications.
that's probably because you don't develop applications, so you can
afford to be naive about them.

Keith

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 13 Jul 2007 22:50:43 +0200

On 13-jul-2007, at 22:11, Hannes Tschofenig wrote:

> As Phillip stated, I don't see the problem with future  
> applications. Compare this with the security aspects that are taken  
> care of much more than before when developing new applications NAT  
> traversal is just another thing to think about as a protocol designer.

There is no magical "NAT traversal" switch that you can flip and your  
protocol will work through NAT with no problems 100% of the time.  
Just like there is no such switch for security.

Yes, there were (are?) protocols that were more NAT-unfriendly than  
they needed to be, case in point FTP. I don't think the IETF creates  
protocols that fail when used through a NAT when it's just as easy to  
make the protocol work though the NAT as is the case with FTP.

However, the reason why MOST protocols/applications have trouble with  
NAT is because they need to receive incoming sessions. Short of  
rewriting the protocol to work over UDP or through a third-party  
server, pretty much the only way to "traverse" NAT in these cases is  
to go up to the NAT device, and ask it to open up a TCP port, pretty  
please with a cherry on top?

This works well if:

- the NAT device is a fairly modern one created for a market where  
this functionality is considered important (i.e., home users)
- the application or the OS implements the necessary open sesame logic
- there is a well-reachable server providing referrals
- there is only a single NAT between the outside and the host trying  
to receive incoming TCP sessions

(There could be a firewall in the way, too, but that's not relevant  
for this discussion.)

The first three are likely to get better in the future, but more than  
one NAT is extremely likely to become more common as we run out of  
IPv4 addresses. Note though that even with the above in place there  
are still problems caused by NAT that can only be solved by  
additional application logic or application layer gateways in the  
NAT. (The case where multi-party referrals by IP address happen. Yes,  
by FQDN would be better but not every host has a working DNS name.)

So whichever way you slice it, the best case scenario for NAT is that  
it doesn't get in the way. The worst case is that it absolutely,  
positively breaks your application despite huge amounts of NAT  
workaround logic and a lot time spent debugging the problem. As with  
most things in life, some people are lucky enough to live in a best  
case world, others are prone to be bitten by the worst case more than  
their fair share.

What I consider the most important problem with NATs is that they  
don't fail gracefully. When a NAT gets in the way, the application  
generally doesn't get to do what it wants to do, but without any  
feedback as to why. This means the user doesn't know what the problem  
is and doesn't have any clue about solving it. It's like a world  
where rather than giving you warnings or tickets, police officers  
sneak up on you from behind and knock you unconscious without you  
knowing why if you break a traffic rule. It's painful and you don't  
understand why it happens. Come to think of it, not unlike trying to  
send files or videoconference using instant messaging with a NAT at  
both ends.

---

From: Keith Moore <[email-masked]>
Date: Fri, 13 Jul 2007 17:13:46 -0400

Iljitsch van Beijnum wrote:
> I don't think the IETF creates protocols that fail when used through a
> NAT when it's just as easy to make the protocol work though the NAT as
> is the case with FTP.
yes, but it's not "just as easy" to make FTP work through the NAT...at
least, not without losing the ability for one host to transfer files
between two other hosts. 

(it turns out that in the modern world, this feature of the FTP protocol
is dangerous for security reasons.  but it was a useful feature, and the
existence of NATs make it difficult to re-implement that feature.)
> to receive incoming TCP sessions
- and the site isn't relying on the NAT to also be a firewall.

...and the only problem I have with the above is that the word MOST can
be misleading.  it's not as if most of the problems with NATs would go
away if only all NATs were to suddenly support UPnP extensions to allow
NAT traversal.   that would certainly help, but significant brain-damage
would remain.  also, your "MOST" is based on how things are today, but
the net seems to change fairly significantly every two years.
> are still problems caused by NAT that can only be solved by additional
> application logic or application layer gateways in the NAT.
and only if the NAT can somehow be aware of every application that needs
to traverse it - including proprietary applications, enterprise-specific
applications, applications that need end-to-end encryption, and so on. 
in other words, putting ALGs in the NATs is not a practical solution.
> (The case where multi-party referrals by IP address happen. Yes, by
> FQDN would be better but not every host has a working DNS name.)
which, coupled with several other reasons, implies that FQDNs would not
necessarily be better.
> case world, others are prone to be bitten by the worst case more than
yup.  the point is that it's a large and diverse network, and sweeping
generalizations about things like how NAT affects that network are
extremely dubious.
> don't fail gracefully. 
what I consider the most important problem with NATs is that they're not
accountable for the damage that they do.  similarly for interception
proxies.  so when the application breaks, the reason it breaks is not
apparent to the user or to the party that installed the box that
modified the traffic, and it's hard to get the problem fixed (e.g. by
firing the sysadmin who installed the damn thing, or by ceasing to do
business with the NAT or proxy vendor that misrepresented his product).

things that actively modify traffic without being visible to end systems
are almost inherently going to cause huge problems if they're widely
deployed.

Keith

---

From: <[email-masked]>
Date: Fri, 13 Jul 2007 22:43:18 +0100

> ...and the only problem I have with the above is that the 
> word MOST can be misleading.  it's not as if most of the 
> problems with NATs would go away if only all NATs were to 
> suddenly support UPnP extensions to allow
> would remain.  also, your "MOST" is based on how things are 
> today, but the net seems to change fairly significantly every 
> two years.

I believe that we need a more general protocol for hosts inside a site
perimeter to communicate with the perimeter gateways and request
services from them. UPnP is not that protocol. In an IPv6 world there
will still be site perimeter gateways which block incoming traffic, just
like PAT/NAT does today. It would simplify life if hosts could register
an interest with their site perimeter gateway so that when a packet of
interest comes along, the gateway can either forward it, or notify the
host that the packet will be queued for pickup. Presumably the
notification and packet release will be done over distances less than a
kilometer or two so that the turnaround time does not prevent TCP
sockets from being opened.

This sort of general protocol still provides site protection. For
instance the site administrators can choose which hosts to parley with.
It could also be leveraged to provide some sort of host proxy services,
i.e. my host tells the site perimeter to accept VoIP calls for me and
forward those calls to host X when I'm not there. When I disconnect or
shutdown my host, keepalives not longer go to the gateway, and any
incoming VoIP calls go to the designated "host proxy" which accepts the
calls for me. Of course this "host proxy" is a fancy answering machine,
or maybe it is a device which can shunt the call to my mobile phone.

Of course, before we can realistically define such a protocol, we need
to define the role of a site perimeter gateway, probably with different
levels of service corresponding to different site sizes and different
administrative models.

Once the world was simple and there were hosts (computers), routers
(special dedicated computers) and bridges. Now it is rather more complex
with firewalls, load balancers, switch/routers and so on. Leaving aside
the question of whether or not an IPv6 Internet site perimeter gateway
needs to be in a single device or not, just what must it do, what might
it do, and what will it not do?

--Michael Dillon

---

From: Melinda Shore <[email-masked]>
Date: Fri, 13 Jul 2007 18:07:30 -0400

On 7/13/07 5:43 PM, "[email-masked]" <[email-masked]> wrote:
> services from them.

We've actually got several of them, starting with SOCKS (which
could have been extended), continuing through RSIP, on to midcom
and SIMCO.  Note that "midcom" was so named under the assumption
that whatever was done would be extensible to other sorts of
middleboxes than firewalls and NATs

We could spend an awful lot of time talking about why none
of them has caught on, but I think it's fair to say that that
failure has not been caused by a perceived lack of generality.

Melinda

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 13 Jul 2007 17:25:56 -0700

There are two fundamental flaws with your claims. 

'What we need is a transition strategy that is more effective than dual
stack.'

&  'The typical consumer does not host servers.'

There is no 'one size fits all' transition strategy, and no amount of hot
air will fix that. Dual-stack is promoted as the primary path because it
allows for an application by application graceful deployment by each
independent organization. Every other approach applies a forcing function
somewhere, and those typically come with a cost that is not localized to the
person doing the work. As you note, it assumes that IPv4 is retained to
allow that smooth transition. If people insist on waiting until there is no
more IPv4 to be had, the state will no longer be dual-stack, it will be a
panic driven deployment of hacks. For dual-stack to work, people need to use
the approach well ahead of IPv4 exhaustion. Claiming we need something more
effective is just hot-air, because 'effectiveness' will be measured
differently in every one of the millions of individual deployment
environments.

The second statement is the result of nat, not a desired situation. The
average non-geek will not intentionally host a service, but anyone that runs
skype or the like without a nat is providing a super-node service. Despite
your claim, typical consumers do this kind of hosting, and would do more of
it if there were no nat. The more we move toward p2p apps being the norm,
the more that services will be hosted on non-traditional 'servers' and at
non-traditional points in the network (ie: the home).  

The real solution to your claim about the need for a more effective strategy
would be to stop allocating IPv4 to the ISPs that do not deliver IPv6 native
service to all of their customers. If the IPv6 native service existed the
dual-stack approach would work just fine. Of course the IETF can't tell the
RIRs to stop allocating IPv4, and since the RIRs are dominated by the ISPs
there is no chance of a policy change that would force deployment of IPv6 to
the edges. 

In the end, the IETF did what it could do by defining a set of tools that
can be used to get IPv6 deployed. The fact that the ISPs are not taking
advantage of those and moving ahead is outside of what we can impact. If
they try and come back with complaints about tools not working, we can work
to fix those, but at the current burn rate the time for any standards fixing
has passed. Even if we modified the spec for transition tools today, by the
time the resulting products hit the streets we would be well into panic mode
from the exhaustion of IPv4.

Essentially the only thing we can do now is stand back and get ready to
roast marshmallows on the fire of the media driven panic when the pool runs
dry. 

Tony

From: Hallam-Baker, Phillip [mailto:[email-masked]] 
Sent: Friday, July 13, 2007 10:57 AM
To: Stephen Sprunk; Keith Moore; Jun-ichiro itojun Hagino
Cc: Paul Hoffman; [email-masked]
Subject: IPv4 to IPv6 transition

I think we need to look beyond whether NAT is evil (or not) and whether
NATPT is the solution (or not) and look to see how we might manage a
transition to IPv6 in a way that is not predicated on holding ISP customers
hostage.

People have been there and done that, anyone remember when the anti-spam
blacklists started talking about 'collateral damage' with great glee? Within
a very short time a very large number of email admins hated the self
appointed maintainers of the blacklists more than the spammers.

Clearly the IPv4 Internet is going to run out of addresses. That does not
mean that IPv4 will go away however. As far as the ISPs are concerned
IPv4+NAT works just fine for residential connections. 

What we need is a transition strategy that is more effective than dual
stack. IPv6 is not going to work as a solution to the IPv4 address space
crunch if every IPv6 Internet user has to have an IPv4 address as well.

This strongly suggests to me that during the transition, a period I expect
to last until 2025, we will want the standard Internet allocation to be a
/64 of IPv6 plus a share in a pool of IPv4 addreses behind a NAT.

What I would like to get to is a situation where a consumer can 1) purchase
Internet connectivity as a commodity with a well defined SLA that assures
them that the connection will work for the purposes they wish to use it 2)
obtain a report from their Internet gateway device(s) that tells them
whether the SLA is being met or not. 

>From the point of view of the consumer all that matters is that their client
applications and their peer-2-peer applications work. The typical consumer
does not host servers at their home and we want the sophisticated consumer
to move to IPv6.

Most application protocols work just fine behind NAT. FTP works with an ugly
work-around. The main protocol that breaks down is SIP. I am mighty
unimpressed by the fact that when I plug the VOIP connector made by vendor X
into the wirless/NAT box made by vendor X that I have to muck about entering
port forwarding controls by hand. And even less impressed by the fact that a
good 50% of the anti-NAT sentiment on this list comes from employees of
vendor X.

STUN does not appear to me to be an architecturally principled approach, it
is a work around.

The way to fix this situation in my view is to make the NAT box SIP aware by
building a SIP proxy capability into the NAT box. The designers of NAT boxes
go to great efforts to try to work around applications. Leave approaches
such as STUN to the case where you are dealing with a legacy box.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 14 Jul 2007 09:29:36 +0900 (JST)

> late to punish them, I fear :)

	no, the people who have implemented your applications that are written in
	IPv4-only and NAT-unfriendly, to be IPv4/v6 bilingual.  i do not care
	about NAT (un)friendliness, i just need it to support IPv6.

> automatically work with IPv6.

	well, that depends on what kind of programming language you will be
	using.  Python uses a model where you explicitly need to invoke bind(2)
	and getaddrinfo(3), so the programmer has to be knowledgeable enough
	to handle IPv4/v6 stuff.  iirc Ruby TCPSocket class embeds all the
	details about getaddrinfo(3) loop within the class/instance method, 
	so you do not have to care about which IP version is in use.

> computing you probably aren't aware of them.

	may i talk with you/designer of PVM/MPI code so that they can implement
	them in IPv6-friendly manner?  privately.

> that seems like a very promising avenue)

	there were tons of multipath TCP drafts, but there's no real
	authentication so all of them failed badly.  so i see some future in ssh.

> solution only solves the problem for two-node applications.

	please tell me, your apps are totally multicast or broadcast?
	if not, we need to solve 2-nodes communication first, then you can
	solve communication among n (n could be very big) nodes.

> and to keep making programmers' jobs more difficult.

	then use vendor libraries that are URL-based.

> have a simplistic view of the application world!)

	??? i do not get your point.  you would like to be lazy, then use
	libraries that are based on URLs.  otherwise, you have to use
	getaddrinfo(3).  other than that, either your design is broken or
	you are lazy.

itojun

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 14 Jul 2007 07:50:49 +0100

Agree and moreover, dual-stack works with private IPv4 addresses behind NAT,
so not an issue.

Regards,
Jordi

De: Tony Hain <[email-masked]>
Responder a: <[email-masked]>
Fecha: Fri, 13 Jul 2007 17:25:56 -0700
Para: "'Hallam-Baker, Phillip'" <[email-masked]>, 'Stephen Sprunk'
<[email-masked]>, 'Keith Moore' <[email-masked]>, 'Jun-ichiro itojun
Hagino' <[email-masked]>
CC: 'Paul Hoffman' <[email-masked]>, <[email-masked]>
Asunto: RE: IPv4 to IPv6 transition

There are two fundamental flaws with your claims.
'What we need is a transition strategy that is more effective than dual
stack.'
&  'The typical consumer does not host serversŠ'

 

 
Tony

**********************************************
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: Hannes Tschofenig <[email-masked]>
Date: Sat, 14 Jul 2007 17:05:06 +0200

Fact: There are NATs and stateful packet filtering firewalls that cause 
problems for some applications.

It is quite likely that these devices will not go away.

Phillip also seems to have this view. I replied to him with regard to 
the conclusion he draw. He seems to think that the right way to deal 
with these boxes is to put application layer functionality on NATs (and 
potentially firewalls as well).

I replied to his mail since I don't believe this is the right approach. 
Instead, I believe that the current work on legacy NAT traversal is 
already doing a good job. There is, however, room for improvement by 
allowing the end host to interact with NATs and firewalls. Some folks 
are working on this subject already for some time.

Does this make sense to you?

Ciao
Hannes

Iljitsch van Beijnum wrote:
>> Compare this with the security aspects that are taken care of much 
>> more than before when developing new applications NAT traversal is 
>> just another thing to think about as a protocol designer.
>
> protocol will work through NAT with no problems 100% of the time. Just 
> like there is no such switch for security.
>
> application logic or application layer gateways in the NAT. (The case 
> where multi-party referrals by IP address happen. Yes, by FQDN would 
> be better but not every host has a working DNS name.)
>
> is and doesn't have any clue about solving it. It's like a world where 
> rather than giving you warnings or tickets, police officers sneak up 
> on you from behind and knock you unconscious without you knowing why 
> if you break a traffic rule. It's painful and you don't understand why 
> it happens. Come to think of it, not unlike trying to send files or 
> videoconference using instant messaging with a NAT at both ends.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 14 Jul 2007 11:10:53 -0500

>> v6-capable, though I'd still debate whether it's the majority.
>> Very, very few of those hosts have working v6 connectivity
>> because there's some device(s) or provider(s) between the
>> host and the DFZ that are v4-only.
>

I do not consider a host dual-stacked, regardless of whether it's 
v6-capable, unless it can actually talk to remote hosts via v6.  That may be 
imprecise on my part, but it's all that matters in the end.

>> It's humans and software, not hardware, that is generally the
>> problem getting v6 deployed.
>
> agreed about humans - mindshare is the hardest thing to
> overcome.  the software/hardware question is a distinction
> without a significant difference.   if the products (you think) you
> need to secure your network aren't shipping, it doesn't matter
> much whether what you need is new hardware or a software
> upgrade.  often, that's just a matter of packaging.

Ah, but there is a difference.  Hardware is purchased in a 3+ year cycle, 
and generally involves significant capital outlay.  Most hardware is 
v6-capable by this point, though apparently there's still issues in the 
load-balancer space that are preventing major content sites from 
dual-stacking.

OTOH, v6 software is still not available from the majority of vendors, but 
if they do release it, it could be a free update (perhaps within the terms 
of a service contract) and deployed at any time.

The distinction is moot, I'll agree, in parts of the market like consumer 
CPE where the vendors have a history of only releasing new software on new 
hardware, so a v6 upgrade will require hundreds of millions of people to buy 
new boxes even though their existing boxes would do v6 just fine if the 
vendors bothered to release new code for them.

>> There's a lot of focus on NAT-PT for v6 sites to access
>> remote v4-only sites; I'm focusing on the case of v4-only sites
>> using NAT-PT to access remote v6-only sites.
>
> that's certainly an important case, but there are better ways
> than NAT-PT for v6-only sites to provide services to v4-only
> users.

Perhaps.  However, every other model I've seen assumes that all of those 
v6-only sites should pay the cost of making their services v4-accessible. 
That puts the cost in the wrong place, since it's v4-only sites that should 
be penalized for being laggards -- not the v6 early adopters, and also 
assumes that v4 addresses will remain available for them to implement those 
solutions.  In a few years, that will no longer be true.

>> No, the second incentive remains.  Fully deploying v6 is still
>> a good idea because it removes the problems inherent to
>> NAT-PT, which I've already acknowledged.
>
> yes, but everyone else's NAT-PT boxes still keep you from
> getting most of the benefit from your upgrade to full IPv6.

In the short term, yes.  OTOH, if everyone deploys NAT-PT today, then 
tomorrow it will _appear_ that the entire Internet is v6-capable, and I can 
convince management that deploying v6 "for real" is worth the effort. 
Today, there is virtually nobody I can reach with v6, so management isn't 
interested, resulting in a chicken-and-egg problem.

> IETF is useless if it doesn't try to describe what will work well
> in the long term.

We all agree on the long-term vision.  What we disagree on is what is the 
best method to get there from where we are today.  I think that NAT-PT is no 
less evil than the v4 NAT we're using now and will get us to a NAT-free 
v6-only Internet faster than other strategies proposed.  The shorter the 
transition is, the better things will be for all of us in the end.

S

---

From: Douglas Otis <[email-masked]>
Date: Sat, 14 Jul 2007 14:45:50 -0700

On Jul 13, 2007, at 10:57 AM, Hallam-Baker, Phillip wrote:

> I think we need to look beyond whether NAT is evil (or not) and  
> whether NATPT is the solution (or not) and look to see how we might  
> manage a transition to IPv6 in a way that is not predicated on  
> holding ISP customers hostage.
>
> People have been there and done that, anyone remember when the anti- 
> spam blacklists started talking about 'collateral damage' with  
> great glee? Within a very short time a very large number of email  
> admins hated the self appointed maintainers of the blacklists more  
> than the spammers.
>
Anyone with a published mailbox not protected by a blocking strategy  
quickly learns email is dysfunctional.  Lost DSNs of silently  
discarded messages, or messages directed to a junk folders never  
reviewed are all too common problems.  Black-hole lists bounded by AS  
CIDR ranges is not a gleeful strategy.  Some ISPs host servers  
involved in nefarious activities and reassign addresses periodically  
to thwart a per address blocking strategy.

To disabuse unfair accusations of abusing the service, we will offer  
a full range of blocking strategies freely selected by each  
customer.  Customers can then find their optimal balance between  
filtering and IP address blocking techniques of which there are  
many.  Unfortunately, few filtering applications alone are able to  
handle the current level of abuse without address black-holing.  And  
unfortunately, offering a more graduated approach increases the level  
of abuse seen on the Internet as a whole.

IPv6 will not make this problem go away.  IPv6 will necessitate  
development of a means to positively verify the administrative domain  
of the _client_ sending traffic into the public address space before  
the transition to IPv6 can be embraced by existing public messaging  
services.

> We have three Internets: IPV4, IPv4+NAT and IPv6.

Perhaps this breakdown should include these perspectives as well.

	IPv6+6to4, IPv6+NAT.
> This strongly suggests to me that during the transition, a period I  
> expect to last until 2025, we will want the standard Internet  
> allocation to be a /64 of IPv6 plus a share in a pool of IPv4  
> addreses behind a NAT.
>
The correlation of IPv6 addresses within IPv4 space might be  
dynamically assigned by newer services, such as PNRP.  NATs will  
remain a part of the Internet long into the foreseeable future,  
regardless of what might be said or done.  Perhaps new types of DNS  
records need to be developed to express complex paths now required by  
today's applications operating within the reality of mixed  
topologies.  Such navigation will likely be handled at what might be  
seen as new sub-layers.

> What I would like to get to is a situation where a consumer can
>
> 1) purchase Internet connectivity as a commodity with a well  
> defined SLA that assures them that the connection will work for the  
> purposes they wish to use it
>
> 2) obtain a report from their Internet gateway device(s) that tells  
> them whether the SLA is being met or not.
>
When an ISP permits their customers to abuse the Internet, recipients  
of this abuse MUST BE ALLOWED to block abusive traffic.  These blocks  
will not disappear quickly, nor are these blocks directly managed by  
ISPs offering now blocked outbound connectivity.  A customer of such  
an ISP may have no recourse, but to seek different providers  
regardless of what is within their SLA.  There is no need to receive  
a report, the customer will be aware of the problem rather quickly.   
Perhaps this can be solved by offering a "tasting" period. ; )

> From the point of view of the consumer all that matters is that  
> their client applications and their peer-2-peer applications work.  
> The typical consumer does not host servers at their home and we  
> want the sophisticated consumer to move to IPv6.

Consumers often violate the AUP of their residential Internet  
provider.  Acknowledging this, some AUPs are making exceptions where  
semi-private versus public server use might be allowed.  These  
exceptions often permits things like remote access or various peer-to- 
peer applications.  These applications are fairly common and  
supported by various mechanisms included in typical IPv4 wireless  
routers.

> Most application protocols work just fine behind NAT. FTP works  
> with an ugly work-around. The main protocol that breaks down is  
> SIP. I am mighty unimpressed by the fact that when I plug the VOIP  
> connector made by vendor X into the wirless/NAT box made by vendor  
> X that I have to muck about entering port forwarding controls by  
> hand. And even less impressed by the fact that a good 50% of the  
> anti-NAT sentiment on this list comes from employees of vendor X.
>
Techniques employed to navigate through NAT and firewall barriers are  
often based upon various assumptions.  The small percentage of cases  
where the assumptions prove wrong causing techniques fail, will  
consume a disproportionate amount of customer support.  Even when  
applications fail within a small percentage of network environments,  
these failures are also likely to cause the application to fail  
within the marketplace.

> aware by building a SIP proxy capability into the NAT box. The  
> designers of NAT boxes go to great efforts to try to work around  
> applications. Leave approaches such as STUN to the case where you  
> are dealing with a legacy box.

There should concern about SIP abuse when switching is placed within  
a typical NAT.  This would likely cause consumers to confront an  
abuse problem that is difficult to solve.  Their recourse might be to  
simply disable their service and utilize centralized services which  
often offer PSTN connectivity as well.

-Doug

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Jul 2007 10:13:40 +0200

> failure has not been caused by a perceived lack of generality.

Maybe by a lack of simplicity?

draft-woodyatt-ald-01 is a recent proposal.

     Brian

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 16 Jul 2007 10:30:18 +0200

Hi Brian,

regarding lack of simplicity: Different solutions build on different 
assumptions. If you make specific assumptions then the solution is much 
simpler.

There is a recent document that aims to compare some of the NAT / 
firewall protocol proposals:
http://www.ietf.org/internet-drafts/draft-eggert-middlebox-control-survey-01.txt

It is not yet finished but might give you an idea what the different 
assumptions of some of the proposals are.

Ciao
Hannes

---

From: Melinda Shore <[email-masked]>
Date: Mon, 16 Jul 2007 07:51:38 -0400

> Maybe by a lack of simplicity?

Midcom and SIMCO are very simple.  I think that there are a few problems,
which taken in aggregate make NAT "control" a hard sell.  One is that
in even modestly complex networks either the application has to be
aware of and make decisions about topology or that the traversal
mechanism has to be aware of and make decisions about topology.  I
started the network-friendly midcom stuff (which turned into the
NSIS nat and firewall work) because of that, but after having spent
more time with it I really think it is not deployable in real
networks, which we can talk about some other time.  Another problem
is the lack of naming and lookup facilities.  DNS SRV records are
probably going to be as good as it gets.  VoIP protocols and others
that make use of embedded addresses actually do have an advantage here,
because they're able to transmit an acquired address in the application
signaling.  However, that won't help with servers, P2P, and so on.

And, of course, there are heaps of political issues.  Some of them
are as crude as being about who controls what, but there are some more
subtle ones around business models (the last time I talked about this
Keith insisted that the "IETF doesn't do business models," and I still
encourage him to take a good look at what's going on in what's now the
RAI area), as well, that shape the technical decisions that are made.

Melinda

---

From: Keith Moore <[email-masked]>
Date: Mon, 16 Jul 2007 17:47:50 -0400

> 	about NAT (un)friendliness, i just need it to support IPv6.
you have it backwards.  It is the NATs that are unfriendly to apps, not
the other way around. 

it's easy to write a distributed app that can handle the case where all
nodes are IPv4, or the case where all nodes are IPv6.  it is much more
difficult to write such an app that can handle the case where some nodes
are IPv4, some are IPv6, some are both, and there is a need to
communicate between arbitrary pairs of nodes within the app and to allow
some nodes to do referrals to other nodes.  DNS names are not a good way
to solve this problem for reasons of performance and reliability and
because a DNS name does not, in practice, uniquely bind to a particular
host.
> 	so you do not have to care about which IP version is in use.
it is not reasonable to assume that for all apps the correct model is to
do a DNS lookup and then try the resulting IP addresses one at a time
until a connection succeeds for one of them. 

that, and getaddrinfo() is broken in a great many ways: it isn't tied to
DNS (so if your app is defined to use DNS then you can't trust
getaddrinfo() to do what your app needs); even if the implementation
does use DNS, getaddrinfo() can only do A and AAAA queries, it's not
asynchronous, and the whole idea that a host stack can select a
source/destination address pair by trial-and-error and get good results
within a reasonable time is, quite frankly, a joke.

> 	them in IPv6-friendly manner?  privately.
I don't work there any more, and none of the people whom I knew that
worked on those codes work there any more either.
> 	authentication so all of them failed badly.  so i see some future in ssh.
ssh is not a bad protocol, but it doesn't solve the
multiple-addresses-per-host problem, even if you change it to allow
peers to re-connect (which would be a nice feature).
> 	solve communication among n (n could be very big) nodes.
this isn't a multicast or broadcast problem I'm speaking of.  I'm
speaking of the need for the network to provide complete connectivity
between arbitrary pairs of nodes in a distributed system.
> 	then use vendor libraries that are URL-based.
my, you have a simplistic view of the application world!

Keith

---

From: Douglas Otis <[email-masked]>
Date: Mon, 16 Jul 2007 16:01:21 -0700

On Jul 16, 2007, at 4:51 AM, Melinda Shore wrote:

> Another problem is the lack of naming and lookup facilities.  DNS  
> SRV records are probably going to be as good as it gets.  VoIP  
> protocols and others that make use of embedded addresses actually  
> do have an advantage here, because they're able to transmit an  
> acquired address in the application signaling.  However, that won't  
> help with servers, P2P, and so on.

Complex arrangements are currently are being establishing for peer-to- 
peer communications.  These arrangements entail a structure of IP  
addresses used to navigate through various devices supporting  
protocols like Teredo.  DNS currently does not provide a specific  
resource record type for this purpose, although conceivably fields  
such as Priority within an SRV resource record could define a  
topology structure.  These addresses might then be employed at  
different stages of a transport topology.  DNS SRV records normally  
return a list of IP addresses as additional information, where an  
application would then need to arrange this information.

Although DNS is not normally used in this fashion, for our  
application, DNS servers are updated every so many seconds where each  
contains millions of records.  This is done while responding to tens  
of thousand of queries per second.  DNS protocol is also commonly  
used to track dynamic addresses assigned to residential routers.   
These routers are then associated with internal hosts having a  
dynamic address.  Obviously DNS can handle very dynamic  
environments.  There is little infrastructure to support this type of  
volatility at this time.  This lack of support may change when the  
marketplace desires non-proprietary solutions.

-Doug

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 17 Jul 2007 11:49:45 +0900 (JST)

i guess we are living with very different assumptions.

> you have it backwards.  It is the NATs that are unfriendly to apps, not

	i guess we agree on this point, but recent IETF documents got it
	backwards so i worded it the way presented in the above.

> because a DNS name does not, in practice, uniquely bind to a particular

	sorry, you are, too lazy.  remember the days when we had bitnet,
	decnet and compuserve (niftyserve in japan) in email world.
	we had a lot of technologies, or tricks i would say, to make emails
	get delivered from/to arbitrary networks.

	in this analogy, IPv4 is bitnet/decnet/compuserve and IPv6 is the
	Internet.  of course.

> until a connection succeeds for one of them. 

	without giving out the details of your "correct model" we cannot
	discuss.  go by mathematical rules, first you give me axioms and
	then we talk about your theories.  do not call theories a "fact"
	or "correct model" because we cannot define them.

> asynchronous,

	if you want PTR, MX and NS records, use res_send and stuff.

	use getnameinfo NI_NAMEREQD and getaddrinfo AI_NUMERICHOST if you
	want DNS resolution to happen for certain.

> and the whole idea that a host stack can select a

	we agree on this point.  i'm having trouble understaing the entire
	"source address selection" stuff.  it won't get deployed nor properly
	managed.

> worked on those codes work there any more either.

	ok, you need bump-in-the-stack (hitachi) or bump-in-the-library (erik
	nordmark/sun microsystems).

> peers to re-connect (which would be a nice feature).

	what is the problem you have with "multiple-addresses-per-host" problem?
	i never had any problem even with IPv4.

> between arbitrary pairs of nodes in a distributed system.

	describe what is "complete connectivity" in your definition.
	are you talking about QoS?

> my, you have a simplistic view of the application world!

	you did not give me the details, so i have to guessing.

	the last note.  i guess i have a clear idea about how to make Skype
	dual stack.  current Skype protocol is totally IPv4-only (see "silver
	needle in skype" paper), but i can make it dual stack, i mean,
	mixture of IPv4-only, IPv4/v6 dual stack and IPv6-only.
	if you are the IPv6 guy in Skype, we need to talk :-)

itojun

---

From: Keith Moore <[email-masked]>
Date: Mon, 16 Jul 2007 23:48:22 -0400

> 	i guess we are living with very different assumptions.
it's just that the needs of applications vary as widely as the needs of
users.  it's not as if all Internet users do nothing but email and the
web, and neither is it as if all Internet applications are like HTTP or ssh.
> 	in this analogy, IPv4 is bitnet/decnet/compuserve and IPv6 is the
yes, I remember those, and I also remember the problems we had trying to
make all of that work well - in particular, the problem of rewriting
addresses so that the mail would still be replyable after it crossed
multiple gateway boundaries.  (actually I wrote a thesis on the topic). 
I'm sure my experience with email addressing and gateways is part of why
I could see the problems with NAT earlier than most people.

of course, it's not as if every application in the v4/v6 world is like
email.  at least some of those email protocols were designed to be
store-and-forward and to allow email to be transmitted across networks
without end-to-end connectivity.    store-and-forward isn't appropriate
for every applications protocol.  (and I'd even argue that it probably
shouldn't be used for email anymore, at least not in the way that SMTP
currently does it, because it's really hard to arrange for errors to be
reliably reported to the party that needs to know about them.)
> 	or "correct model" because we cannot define them.
I don't think there is a single "correct model" for all apps that works
in a network where hosts have multiple addresses and the performance can
vary significantly depending on which address pair you choose.

ideally, from the application's point-of-view, the network would always
perform well enough to suit the needs of the application and it wouldn't
matter which source and destination address were used.  also, any
address would be reachable from any point in the network.  the
traditional IPv4 network approximately fulfilled both conditions; the
current IPv4 network with NATs still mostly fulfills the first one. 
having multiple addresses per host/network be the normal case in IPv6
threatens to remove the first condition, and having a mixed v4/v6
network nixes the second one.
> 	want DNS resolution to happen for certain.
I don't recall that this guaranteed by the API specification.
> 	"source address selection" stuff.  it won't get deployed nor properly
agreed.
> 	nordmark/sun microsystems).
nah.  basically it's easy to port either system to a pure IPv6 network,
and this might have already been done; it's just hard to run an app that
expects complete connectivity among all nodes on a mixed IPv4/IPv6
network. 
>> 	i never had any problem even with IPv4.
it's the fact that in IPv6 if you don't select the best source and
destination address to talk to a node, you might either fail to get a
connection (and have to wait a long time for a timeout), or you might
get a connection that performs much worse than some other
source/destination address pair you could have used.  this was true for
IPv4 nodes with multiple interfaces also, but this was mostly solved in
IPv4 by not having multiple active network interfaces.  (people tried
it, it didn't work well, so they stopped doing it.)  In IPv6 the normal
situation for hosts on multihomed networks is to have multiple
addresses, and there are several pressures to have additional addresses
- like for mobility, or using ULIAs for local apps on enterprise
networks so that they won't be affected by renumbering.  so address
selection becomes more important in IPv6 than it was in IPv4.
> 	are you talking about QoS?
if you are building a distributed computation system and you want it to
perform well then any node should be able to send packets to any other
node, even if some of those nodes are IPv4 only and others are IPv6 only.
> 	if you are the IPv6 guy in Skype, we need to talk :-)
yeah, I think I see how to make Skype dual stack too, since they already
have the infrastructure needed to relay packets between two nodes that
are both behind NAT - they could use the same kind of infrastructure to
relay packets between v4 and v6 realms.  but I'm not the ipv6 guy in
Skype.  :)

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 17 Jul 2007 13:38:17 +0900 (JST)

> web, and neither is it as if all Internet applications are like HTTP or ssh.

	if you are not under NDA, could you please be more specific?  source
	code, RFC/draft for the protocol, whatever?  i'm getting tired of this
	guessing games.

> reliably reported to the party that needs to know about them.)

	well, i'm sure there still are instances of Lotus Notes running in
	ancient enterprises.

	once you run ALG (which i guess you do not like) IPv6-to-IPv4 or IPv4-to-
	IPv6 looks much like SMTP relaying.  if you could give v6ops people your
	comments from your experiences, it would be helpful.  i know we have been
	trying and tired to death, but this year is THE right time.

> vary significantly depending on which address pair you choose.

	yup, there's no single truth.  we agree on that.

> I don't recall that this guaranteed by the API specification.

	do not underestimate my paranoid-ness, i'm an OpenBSD developer, and
	i'm proud of it!  i've met both Steve Mann and Richard Stallman face
	to face, though i don't think they remember me.

	- getaddrinfo/getnameinfo standards do not say a thing about DNS lookup
	  so you cannot trust it.  of course if analyze the source code, you may.
	- res_send/res_query are not a standard so the behavior is not defined
	  in documents.  of course if analyze the source code, you may.
	- even if you write code that plays with UDP/TCP socket, you are unsure
	  if there's any tricks inside OS kernel, like host firewall blocking
	  or rewriting your queries/responses.  of course if analyze the source
	  code, you may.
	- even if you trust your OS kernel, you cannot trust your router,
	  especially when it implements NAT and you are using it with NAT
	  disabled.  of course if analyze the source code, you may, but the
	  likelyhood of getting source code is rather low.
	- even if you trust your router, you would not be able to trust your ISP,
	  or peering ISPs.  now it became impossible to look at source code,
	  and/or configuration of all the routers.
	- even if you trust your L3 stuff, you cannot trust DNS trees.
	  (1) how can you trust your libc resolver?  it is the first 3 bullets
	      above.
	  (2) how can you trust your recursive resolver, the address listed in
	      /etc/resolv.conf?  even if you run recursive resolver, can you
	      trust guys behind Paul Vixie or djb?
	  (3) can you trust recursive responses from random name servers, when
	      we do not have DNSSEC deployed?
	  (4) even if you have DNSSEC, how can you be sure that you are using the
	      right root DNS server/DNSSEC signing chain, and how can you be
	      sure that all of the signing keys are not compromised?

> expects complete connectivity among all nodes on a mixed IPv4/IPv6

	please contain yourself from using "complete", "fact", "truth", "god",
	and whatever.  in Japan there are 8,000,000 god*s* and father of jesus
	could be one of them.

> selection becomes more important in IPv6 than it was in IPv4.

	ok, so you are basically worried about uRPF, performance difference,
	and/or firewalling policy differences when you have multiple exit links.

	do not take it as a self-promotion, but my take on this is in RFC3178.

> relay packets between v4 and v6 realms.  but I'm not the ipv6 guy in

	so i can solve problem for Skype, so i guess i can solve problem for
	your "distributed computation system".  want to hire a consultant? :-P

itojun

---

From: Keith Moore <[email-masked]>
Date: Tue, 17 Jul 2007 02:38:03 -0400

> 	code, RFC/draft for the protocol, whatever?  i'm getting tired of this
what do you want me to do, describe in detail every distributed
application that I've ever worked with?  I'm not talking about any
specific application, I'm generalizing from several applications that
I've worked with and/or am otherwise familiar with.
> 	IPv6 looks much like SMTP relaying.
true.  ALGs are okay for applications that have explicit intermediaries,
like SMTP.   I don't like ALGs so much when they're used as interception
proxies.  sometimes they work okay, sometimes not.

> 	do not underestimate my paranoid-ness, i'm an OpenBSD developer
somehow, I think this should be on a t-shirt,  or a bumper sticker.  :)

[analysis of the many layers that could potentially modify traffic omitted]

agree with all of those.  but it sounds like you're close to arguing
that because there are so many other things that can screw with DNS,
it's okay for getaddrinfo() to return bogus results too.

in general, things that alter or spoof network traffic are evil.  they
are evil whether the traffic being altered or spoofed is IP, TCP, UDP,
DNS, or a higher-layer protocol; they are evil whether the altering or
spoofing is being done "on the wire" (by modifying packets) or at the
API level.   all of those things make it more difficult for applications
to get consistent, repeatable behavior out of the network.

> 	do not take it as a self-promotion, but my take on this is in RFC3178.
it's not just multiple exit links, it's having multiple addresses per
host for any number of reasons.  (mobility, renumbering, the desire to
have stable local addresses, and also the possibility of multiple active
network interfaces)

but things like RFC 3178 do help.  if we can get back to the expectation
that one address per host is the normal case, we'll make life much
simpler for application writers.
> 	your "distributed computation system".  want to hire a consultant? :-P
I can solve it too, and have done so on a couple of occasions.  but I
don't pretend that it's easy to retro-fit every existing distributed
application (or to build every new distributed application) to handle
multiple realms.  NATs have drastically raised the burden on
applications by dividing the Internet up into multiple address realms;
similarly, IPv4/IPv6 coexistence also divides the Internet up into
multiple address realms.  Thus a "mixed" IPv4/IPv6 network is almost as
dysfunctional as a NATted IPv4 network.

Keith

---

From: <[email-masked]>
Date: Tue, 17 Jul 2007 10:04:09 +0100

> DNS names are not a 
> good way to solve this problem for reasons of performance and 
> reliability and because a DNS name does not, in practice, 
> uniquely bind to a particular host.

And DNS names are not in use on all Internet Protocol internetworks.
This is because of the security issues of trusting a third party to
supply an address-name mapping.

> it is not reasonable to assume that for all apps the correct 
> model is to do a DNS lookup and then try the resulting IP 
> addresses one at a time until a connection succeeds for one of them. 

For instance, applications in the global finance industry typically do
not do any DNS lookups at all. Admittedly, they often have a list of
destination IP addresses which they try until a connection succeeds. But
the point is that IPv6 transition has to be explicitly programmed into
each and every application and it has to be embedded in the operational
processes as well.
   
> my, you have a simplistic view of the application world!

This can be solved by talking to network operators, large consultancy
firms and large enterprises. One can learn a lot about how IP networks
are really implemented if one is willing to listen and learn.

--Michael Dillon

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Jul 2007 11:54:15 +0200

On 2007-07-17 11:04, [email-masked] wrote:
...
> each and every application and it has to be embedded in the operational

Which is in fact the exact same logic a dual stack application should
follow after calling getaddrinfo(). Whether or not you resolve a name
to get the list of addresses, you need the logic to try all available
addresses in turn.

otoh, I've never yet found an application programmer who found upgrading
to the new socket API to be especially challenging; it's just work.
As Michael says, it has to be done for each application.

     Brian

---

From: Keith Moore <[email-masked]>
Date: Tue, 17 Jul 2007 08:04:27 -0400

> to get the list of addresses, you need the logic to try all available
well, it depends on the application.  sometimes the delay required to
try all of the addresses in turn until one is found to work is not
acceptable, and at other times it's very annoying... particularly when
the default address selection rules don't predict which
(source,destination) address pair is going to work best.
> to the new socket API to be especially challenging; it's just work.
the problem isn't the differences between the v4 and v6 socket API.  the
problem is the expectation that in IPv6 the application has to choose
which address(es) to use, coupled with the high probability that the
first address(es) chosen will not work well.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Jul 2007 14:39:45 +0200

On 2007-07-17 14:04, Keith Moore wrote:
...
> the

What high probability is that? The presumption is that the RFC 4384
policy will put the one most likely to work first in the list.

Why is this any different from IPv4 with alternate addresses?

    Brian

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 17 Jul 2007 21:57:26 +0900 (JST)

from what we have exchanged, the only things we do not agree with each
	other are:
	- you do not believe IPv4/v6 mixed environment would work, or too tough
	  to make it work that it is not justifiable.  also you see some problem
	  in nodes with multiple addresses.
	- i do believe it would work ok

> I've worked with and/or am otherwise familiar with.

	when you generalize things you might have missed some of the details,
	so if you could please send me pointers to details (privately).

> proxies.  sometimes they work okay, sometimes not.

	yup.

> somehow, I think this should be on a t-shirt,  or a bumper sticker.  :)

	heh, maybe.

> it's okay for getaddrinfo() to return bogus results too.

	i did not say that.  what i was trying to say are below:
	- you said that you do not trust getaddrinfo/getnameinfo but you seem to
	  trust other DNS functions/responses.
	- under what kind of condition would you trust DNS, and would you not?
	- are you sure it is ok when you trust it?

> have stable local addresses, and also the possibility of multiple active

	note that "client machines with multiple IP address" has been a
	common practice even for IPv4, more than 15 years at least.  i had the
	first laptop when i was in university, i ran 386BSD (4.4BSD) so that
	makes it around 15 years ago.

	mobility - i do not see your problem, maybe mobile-ip6 guys would
		want to speak up
	renumbering - multiple address DO help
	stable local address - well, define "stable"
	multiple active network interfaces - it is a common practice,
		use MacOS X machines with wireless and ethernet and switch them
		over time.  TCP connection would not survive, which is a problem,
		but other than that, things are seamless (like browsers).

> simpler for application writers.

	the thing is, application writers does not really need to choose
	addresses to be used, as long as you write a program/protocol spec
	so that it does not embed IPv4/v6 addresses or DNS names.  if you
	embed it, you would want to use DNS names instead of IPv4/v6 addresses,
	as you will want your application to work ok with the next protocol
	that would be introduced after IPv6.  i would not call it IPv8 :-P

> dysfunctional as a NATted IPv4 network.

	ok, i can understand your concern, but we need to do it anyways.
	unlike the introduction of IPv4, you cannot set a flag day, can you?

itojun

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 18 Jul 2007 15:20:39 +0200

> selection becomes more important in IPv6 than it was in IPv4.

Moving topology decisions out of the hands of routing protocols and  
the people that build networks into hosts creates a lot of  
complications. BGP as we know it is pretty bad at selecting the best  
path, but it's fairly good at avoiding the bad ones, so it works well  
enough in practice. When you give a host a number of paths (as in  
source/dest address combinations) to choose from, it's doable (but  
not trivial) to avoid the non-working paths, but knowing that path X  
has a much higher capacity than path Y even though path Y does work  
is very hard, especially if we want to look further than the only  
easily measurable quality aspect: the RTT.

But the entire existence of this problem stems from the notion that  
the entire communication must flow over a single path. If we let  
packets belonging to a single session flow over multiple paths, and  
then use standard windowing techniques such that paths that can  
accept more data get more data and paths that don't don't, we  
actually get to use the full aggregate capacity of the entire set of  
paths, and it's no longer necessary to invest complexity in discovery  
functions.

BitTorrent already works like this to some degree by exchanging  
information over a large number of paths concurrently. I've also once  
been involved in implementing a system where we did this "by hand" by  
using several different TCP sessions. This didn't work at first  
because the program would round robin and block writing to the slow  
sessions so 10 + 100 Mbps = 20 Mbps but after fixing this 10 + 100  
Mbps = 110 Mbps.

Making this work well for applications that are interested in other  
quality aspects than aggregate throughput would be more difficult,  
though, but probably not as difficult as deducing QoS information  
from random sets of source/dest addresses.

---

From: <[email-masked]>
Date: Wed, 18 Jul 2007 15:23:53 +0100

> But the entire existence of this problem stems from the 
> notion that the entire communication must flow over a single 
> path. 

MPLS ECMP?
RFC 4928?

--Michael Dillon

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Mon, 23 Jul 2007 05:00:27 +0900 (JST)

> somehow, I think this should be on a t-shirt,  or a bumper sticker.  :)

	http://www.shirtcity.com/shop/index.php?file_merchandising=large&actual_merchant_article_serial_number=11&backjump_page=3&PHPSESSID=0be4b41bcaa11ad9eb49adb3bd9c61d5

itojun