Subject: [Fwd: I-D Action:draft-rosenberg-internet-waist-hourglass-00.txt]

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Feb 2008 11:06:29 +0200

Hi Jonathan,
Hi all,

I read through the document and was not quite sure why you wrote it.
Everyone knows this already.

Ciao
Hannes

-------- Original Message --------
Subject: 	I-D Action:draft-rosenberg-internet-waist-hourglass-00.txt
Date: 	Mon, 11 Feb 2008 19:30:01 -0800 (PST)
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : UDP and TCP as the New Waist of the Internet Hourglass
	Author(s)       : J. Rosenberg
	Filename        : draft-rosenberg-internet-waist-hourglass-00.txt
	Pages           : 8
	Date            : 2008-02-11

One of the fundamental design principles of the Internet is that IP
represents a common intermediate protocol layer, linking together a
variety of link layer technologies underneath with a large number of
applications on top.  When drawn graphically, this can be show as an
hourglass with IP in the middle.  The preponderence of NATs and
firewalls in the Internet has changed this reality, such that UDP and
TCP are now the waist of the hourglass.  This document discusses this
change and describes its implications for protocol and application
design.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rosenberg-internet-waist-hourglass-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-rosenberg-internet-waist-hourglass-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-rosenberg-internet-waist-hourglass-00.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 13 Feb 2008 06:27:53 -0600

Hi, Hannes,

I can't answer for Jonathan, but I wondered the same thing, and decided that 
the answer was probably one of

- "well, if we all know this, what are we doing differently now that we know 
it?", or

- "the GOOD news is that the wasp waist-hourglass is no longer HTTP" 
[RFC3205], or

- "the GREAT news is that the wasp waist-hourglass isn't Skype (yet)".

Not sure which, of course :-)

Thanks,

Spencer, with apologies to Keith Moore [RFC3205}

---

From: <[email-masked]>
Date: Wed, 13 Feb 2008 12:35:48 -0000

> - "the GREAT news is that the wasp waist-hourglass isn't Skype (yet)".

The REALLY GREAT news is that when IP ceased to be the wasp waist, 
TCP/UDP moved to fill that position which implies that having a
wasp waist in the protocol stack is a stable state towards which
the protocol set wants to converge.

Therefore, there is good reason to encourage this wasp-waist to
be the right part of the protocol stack. Which means that we should
conciously think about, and discuss, where the wasp waist should
be. And we should try to reinforce positioning the wasp wasit at
the optimal point of the stack.

Is TCP/UDP the right place which we should try to reinforce, or
should we instead try to move it back down to IP as version 6
becomes more widely deployed?

--Michael Dillon

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 13 Feb 2008 14:02:44 +0100

Michael,

when you think about your comment a bit more then you will realize that it is not up to us to decide how the hour glass (of deployed protocols) looks like.

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Gesendet: Mittwoch, 13. Februar 2008 14:36
> An: [email-masked]
> Betreff: RE: I-D 
> Action:draft-rosenberg-internet-waist-hourglass-00.txt]
> 
> 
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 13 Feb 2008 14:05:16 +0100

Hi Spencer, 

> - "the GOOD news is that the wasp waist-hourglass is no longer HTTP" 

Well. In fact that I wanted to make a similar comment saying that some
people would argue that HTTP is the waist if your communication needs to
work in an enterprise setting as well. 

> Not sure which, of course :-)

There is something that could be said as an implication of these
aspects: One needs to have a protocol to establish and maintain
connectivity.

Ciao
Hannes

> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > "FILE 
> /internet-drafts/draft-rosenberg-internet-waist-hourglass-00.txt".
> >

---

From: <[email-masked]>
Date: Wed, 13 Feb 2008 15:43:37 +0200

Hi,

Hannes Tschofenig wrote:
>
>Hi Spencer, 
>
>
>> Hi, Hannes,
>> 
>> I can't answer for Jonathan, but I wondered the same thing, and 
>> decided that the answer was probably one of
>> 
>> - "well, if we all know this, what are we doing differently now that 
>> we know it?", or
>> 
>Well. In fact that I wanted to make a similar comment saying 
>that some people would argue that HTTP is the waist if your 
>communication needs to work in an enterprise setting as well. 
>

True. *If* you want your application to work "everywhere", it better run
on top of HTTP/TLS at least as a fallback. And for many types of
applications the users clearly prefer that it works "everywhere", so the
decision for instance for an IM client developer is not that hard.

Markus

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Feb 2008 08:44:01 -0500

I wrote this because of a discussion that happened during behave at the 
last IETF meeting in Vancouver. There was a presentation in the behave 
working group on NAT ALG for SCTP - when run natively over IP - and I 
found the entire conversation surreal. The entire problem would have 
been moot if SCTP had been designed to run over UDP and not IP.

So apparently its not obvious to everyone that you cannot design 
protocols natively ontop of IP.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Feb 2008 10:59:47 -0500

However, I would really like to reinforce the point from another note. 
There are quite a few contexts where the ability to run a sensible 
transport directly over IP is indeed very useful.  For example, the 
ForCES working group scope is limited (by chart) to the case where the 
control element is near the forwarding element.  I am not worried about 
there being a NAT between those.  So SCTP or DCCP over IP is very relevant.

Yours,
Joel M. Halpern

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Feb 2008 13:44:25 -0500

Well, if history is any guide, eventually people will in fact want to 
run this from someplace a little farther away, and then you're in big 
trouble. So, I think the advice remains the same. There is no drawback 
to having it over UDP to start with - it works when there are no NAT, 
and it can work when there are NAT.

-Jonathan R.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Feb 2008 16:49:07 -0500

I would disagree about "no drawback."
The constraints are:
don't invent new transports
have congestion control

and, for an important part of the traffic, do not have retransmission or 
significant transmission delay (i.e. perform congestion control by 
dropping packets.)

Now, we have SCTP modes and DCCP which can address those needs over IP.
We do not have a defined protocol that runs over UDP that meets those 
constraints.
We could just use UDP.  But the congestion sensitivity aspect was 
actually an important part of the work.
And the scoping (very near, near, or anywhere) was defined in the 
negotiation with the IESG to give us bounds on the work and a framework 
for making these sorts of decisions.

So ignoring the bounds would be quite inappropriate.  And the problem is 
not solvable within the waist you have defined.
Which leaves us with either getting the work done, using IP and suitable 
transports, or extending a very long process much longer.

Not a good choice.

Yours,
Joel

Jonathan Rosenberg wrote:
>> control element is near the forwarding element.  I am not worried 
>> about there being a NAT between those.  So SCTP or DCCP over IP is 
>> very relevant.
>>
>> Yours,
>> Joel M. Halpern
>>
>>
>>> I wrote this because of a discussion that happened during behave at 
>>> the last IETF meeting in Vancouver. There was a presentation in the 
>>> behave working group on NAT ALG for SCTP - when run natively over IP 
>>> - and I found the entire conversation surreal. The entire problem 
>>> would have been moot if SCTP had been designed to run over UDP and 
>>> not IP.
>>>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 14 Feb 2008 08:54:48 +0530

While I disagree with Jonathan's assertion that we should insert an 
entirely useless (for all but NAT) UDP header in front of all new protocols 
we design, I also disagree with Joel's (implicit) assumption that we can't 
implement congestion control on top of UDP.

SCTP mapped on top of UDP would have exactly the same congestion control 
properties as SCTP mapped on top of IP.

Once I've read the draft, I may have other opinions.

              Harald

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Feb 2008 23:06:54 -0500

My assertion wasn't that we can not implement (or even can not define) 
such a thing, but that we had not done so.  Thats why the constraint "do 
not design any new transports" was an important part of the puzzle.
Dan Wing has pointed to an I-D that has started to fill that hole.

Yours,
Joel

Harald Tveit Alvestrand wrote:
> entirely useless (for all but NAT) UDP header in front of all new 
> protocols we design, I also disagree with Joel's (implicit) assumption 
> that we can't implement congestion control on top of UDP.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Feb 2008 11:41:48 +0200

Hi Harald,

the problem with a number of the protocols is that they are later used 
in a different context.

Take SCTP, for example. Initially, it was meant to be used for 
server-to-server communication. Now, some folks obviously want to use it 
in a different way.
Whether this is a good idea or not is a separate question but then you 
obviously run into problems. The real problem, however, starts when you 
do not consider the best current practice in a certain environment. 
Folks working in the RAI area have noticed a couple of years back that 
it is a really good idea todo everything to deal with NATs even if the 
results are not beautiful nor lightweight. This has a lot todo with 
their deployment experience. When you go to other areas in the IETF this 
deployment experience is smaller or missing at all. Consider Mobile IP, 
for example, where many optimize the last hack out of the protocol in 
the believe that their extensions will run only in an IPv6 environment 
without any middleboxes. This has todo with the lack of deployment of 
many of the mobility protocols.

When you want to design a protocol with extensibility in mind then you 
need to consider these aspects. Needless to say that protocols tend to 
get more complex when you support a lot of flexibility.

I agree with your comment about SCTP running on top of UDP to a large 
extend.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Feb 2008 11:42:48 +0200

I am not sure you got Jonathan's idea.

Running protocols on top of UDP does not mean that you don't have 
congestion control.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 14 Feb 2008 11:05:37 +0100

On 13 feb 2008, at 14:44, Jonathan Rosenberg wrote:

> the
> found the entire conversation surreal.

I had the same feeling when reading your draft.

We can have a big, nasty fight about the philosophical points, but  
fortunately, we don't have to, because the whole thing is based on  
incorrect facts. I have never seen a consumer NAT that blocks ICMP.  
I'm 98% sure that path MTU discovery black holes are NOT caused by  
just NAT. Also, most of the NATs I've encountered have no problems  
with non-TCP/UDP protocols (such as proto 41, IPv6-in-IP) except that  
obviously only a single internal host gets to have a mapping for such  
a protocol.

> protocols natively ontop of IP.

You can, it just means that deployment will be harder. In many cases  
that means it's a better tradeoff to encapsulate in UDP or TCP, but  
that is not a universal truism.

As for the philosophical part: I have a big problem with importing  
requirements from NATs and firewalls because their operation isn't  
governed by any specification so it's impossible to fulfill such  
requirements.
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 14 Feb 2008 13:03:16 +0200

Le Thursday 14 February 2008 12:05:37 ext Iljitsch van Beijnum, vous avez 
> incorrect facts. I have never seen a consumer NAT that blocks ICMP.

ICMP is not a transport protocol. It is a control protocol. I similarly have 
yet to see a NAT devices have not impeded IGMP, OSPF, or PIM very much 
either. But I think that is totally beyond the point of Jonathan's draft.

> obviously only a single internal host gets to have a mapping for such

Again, IPv6-in-IP (proto-41), as well as IPIP and GRE are tunneling protocols, 
not really transport protocols. They are typically manually provisioned, so 
that they work. Then again, some people do (have to) use UDP tunneling 
instead (think of Teredo and ESP-in-UDP); also 6to4 does not work through 
many NATs.

> that is not a universal truism.

No no no. I know five IETF transport protocols: the 2 old ones (UDP and TCP), 
and the 3 "new" ones (SCTP, UDP-Lite, DCCP). As a matter of fact, only the 
old ones work through NATs *at* *all*.

SCTP multi-homing is a SCTP-specific problem that is pretty much incompatible 
with how common NATs work.

DCCP connection model is very similar to that of TCP. And UDP-Lite is 
essentially the same as plain UDP. Still, neither of them work through NATs 
at all. When changing the IP address, the transport layer checksum is broken. 
Hence NATs need to be specifically upgraded to handle DCCP and UDP-Lite.

> governed by any specification so it's impossible to fulfill such

What about the BEHAVE working group?

I would argue that Jonathan's document does not go far enough. There are quite 
severe limitations as to the use of TCP through NATs: the passive end cannot 
be NAT'ed.

UDP mostly work, except it is not reliable NAT-to-NAT, and it is unsuitable 
for battery-powered devices, as most NATs and firewalls have too short 
timeouts for UDP flows.

And then comes firewalls, and proxies. So as was already mentioned, one could 
argue the waist hourglass is HTTP and HTTP/SSL, and this discussion is 
irrelevant.

-- 
Rémi Denis-Courmont

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Feb 2008 09:19:54 -0500

Harald Tveit Alvestrand wrote:
> protocols we design,

Well, I'd hardly characterize, "allowing it to work across the public 
Internet" as a property that is useless. Statements like, "useless for 
all but NAT" trivialize what the Internet has evolved into. There is NAT 
everywhere. Lets accept it and design for what the Internet is, and not 
for the Internet as we wish it would be.

You may not like it, but its reality.

-Jonathan R.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 14 Feb 2008 06:51:14 -0800

> for the Internet as we wish it would be.

We don't see NAT on IPv6. However, we do see "statefull firewalls", and they have the same practical effect. They block any conversation if it was not originated "from inside the network", and for that they look at TCP and UDP port numbers. In practice, I expect that IPv6 applications will have to be designed to work over UDP & use an IPv6 variation of STUN to "open the firewall". So, even with IPv6, Jonathan's statement is likely to stand.

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 14 Feb 2008 15:51:21 +0100

> ICMP is not a transport protocol. It is a control protocol.

> Again, IPv6-in-IP (proto-41), as well as IPIP and GRE are tunneling  

Well, Jonathan used any non-TCP, non-UDP and ICMP in particular not  
being allowed through NAT as the underpinning for his reasoning. That  
point is simply incorrect and therefore the whole line of reasoning is  
built on quicksand.

> also 6to4 does not work through many NATs.

The reason that as a rule, you can't do 6to4 through NAT is because  
you don't know your 6to4 prefix if you don't know your real IPv4  
address. Whether the packets make it through is a different question.

> Hence NATs need to be specifically upgraded to handle DCCP and UDP- 

Or, when designing new protocols, the checksum is calculated in such a  
way that address translation isn't a problem. Or the implementation  
discovers the outer IPv4 address and adjusts its checksum calculation  
accordingly. This doesn't make all non-TCP/UDP protocols impossible.

> What about the BEHAVE working group?

What about them? I haven't read the mailinglist for some time, but it  
sure seems there are some weird things going on there.

> So as was already mentioned, one could

Many NATs and firewalls block incoming TCP sessions or unexpected UDP  
packets. So if we use the logic "only stuff that works on 100% of all  
hosts connected to the internet is relevant" then EVERYTHING is  
irrelevant.
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 14 Feb 2008 15:58:50 +0100

On 14 feb 2008, at 15:51, Christian Huitema wrote:

> We don't see NAT on IPv6. However, we do see "statefull firewalls",  
> and they have the same practical effect. They block any conversation  
> if it was not originated "from inside the network", and for that  
> they look at TCP and UDP port numbers. In practice, I expect that  
> IPv6 applications will have to be designed to work over UDP & use an  
> IPv6 variation of STUN to "open the firewall". So, even with IPv6,  
> Jonathan's statement is likely to stand.

Disagree. There is no reason why a stateful firewall would have an  
easier time tracking UDP state than any other non-TCP state when there  
is no address translation.
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Feb 2008 16:59:14 +0200

> hosts connected to the internet is relevant" then EVERYTHING is  

You are missing a really important point: Things just don't work if you 
do not have a protocol for establishing and maintaining the e2e 
connectivity.
SIP (in combination with ICE), for example, is such a protocol that 
allows you todo that. Mobile IP is another one (when you fix various 
things) etc.

It is implicit in Jonathan's draft but maybe it should be made more 
explicit.

Ciao
Hannes

---

From: Melinda Shore <[email-masked]>
Date: Thu, 14 Feb 2008 10:04:26 -0500

> is no address translation.

There's just a lot more experience with UDP than there
is with some other non-TCP protocols.  Engineers have been
more motivated to deal with it than they have with, say, SCTP.

But anyway, firewalls solve a different problem from NAT.
NAT has incidentally been used as a policy device but
a firewall really is a policy device.  So, while it
might be reasonable to say "I need to figure out how
to get across a NAT," it would also be reasonable to
say "I need to figure out how to get across a firewall
without violating access policy."  You definitely do
not want to design a mechanism that enables policy
violation.

Melinda

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 14 Feb 2008 17:09:04 +0200

Le Thursday 14 February 2008 16:51:21 ext Iljitsch van Beijnum, vous avez 
> address. Whether the packets make it through is a different question.

No no no. You can find your external IPv4 address using STUN, Teredo, 
whatismyip.com, you-name-it, and infer the 6to4 prefix from that. You may 
further assume that no other host is using proto-41 within the same NAT.

It still will not work. IPsec pass-through lets you receive traffic from the 
IPsec gateway you sent ESP packets to. But for 6to4 to work, you need to 
receive proto-41 packets from ANY remove peer, owing to the asymmetric 
routing. I did try for real.

(...)
> accordingly. This doesn't make all non-TCP/UDP protocols impossible.

Indeed, but all new "real transport" protocols do re-use the "pseudo-IP 
header" in their checksum computation to date, and I have seen no proposal to 
change this so far.

Also, even then, you're still going to shoot yourself in the foot if multiple 
hosts try to use the same protocol to the same remote node (which is in fact 
quite likely), unless the NAT knows how to mangle port numbers for the 
specific protocol.

> hosts connected to the internet is relevant" then EVERYTHING is

Agreed. It's just a matter of how many nines you want/need to have. I bet only 
HTTP can get one single nine by the way :( i.e. >90%.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 14 Feb 2008 09:10:30 -0600

> is no address translation.

I believe the point here is that a stateful firewall installs a binding 
based on an initial packet from INSIDE the firewall, and removes the packet 
after some inactivity timer expires, and not based on any notion of UDP 
state (!).

So the point is not whether a stateful firewall can track UDP state (!) more 
easily than other non-TCP state, it's that firewall vendors have decided to 
punt on UDP and just run a timer, but they have not decided to punt on all 
non-TCP transport protocols in the same way.

Ignoring the whole "trusted inside/untrusted outside" model for now, of 
course.

Spencer

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Feb 2008 17:13:06 +0200

Hi Melinda,

>   You definitely do

I have just been waiting for this comment.

Interestingly, you could combine mechanisms, namely
* mechanisms that traverse the NAT/firewall and do not require cooperation 
* mechanisms that allow the middlebox to participate

We have seen these mechanisms being proposed in the IETF.
Unfortunately, it was not so easy to convince people that these 
mechanisms would be deployed by middlebox vendors.

Ciao
Hannes

---

From: Ned Freed <[email-masked]>
Date: Thu, 14 Feb 2008 07:11:27 -0800 (PST)

> I had the same feeling when reading your draft.

(I have no skin in this particular game, but some of the assertions below about
what is and isn't deployed out there caught my eye and I thought I'd respond.)

> incorrect facts. I have never seen a consumer NAT that blocks ICMP.

I, OTOH, have recently seen several that give every appearance of doing this. I
have no idea why they do it, but it's incredibly annoying because it turns
connection refusals into timeouts, breaks traceroute, and so on.

Maybe my experience is unusual, but I doubt it. My general lament is that it
seems like it gets harder and harder to find even NATted connectivity that
doesn't have various wierdnesses imposed on it. For example, another major
annoyance are the places that time out connections after five mintues or so
regardless of activity.

> just NAT.

On this we agree.

> Also, most of the NATs I've encountered have no problems

Man, you have no idea how much I wish this were true. I own four fireally/NAT
boxes (two different models, one of which as two firmware variants) and not a
one of the damn things has the ability to open up an IP-level protocol. This
means I can't let 6to4 traffic through and as a result I'm looking at some
fairly significant replacment costs, not to mention the time needed to
transition to new gear.

Mind you, I'm not saying that protocols should always use a UDP
shim layer. But I think the tradeoffs in favor of doing so are a bit stronger
than you seem to think.

				Ned

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 14 Feb 2008 09:43:40 -0600

> shim layer. But I think the tradeoffs in favor of doing so are a bit 

This is my chance to act the naif for Valentine's Day, but ...

I agree that UDP shims improve your ability to get through a NAT in the 
short term. However (and especially given Melinda pointing out that NATs 
impede connectivity for technical reasons, but firewalls impede connectivity 
for policy reasons), we need to recognize that this is an arms race.

You may have better NAT-traversal characteristics using a UDP shim, but as 
soon as some firewall administrator says "gee, I wonder what's running over 
that UDP 5-tuple - gosh, it might be dangerous", you're dead, either way. Is 
there a firewall administrator's guide that DOESN'T say "deny all ports, and 
then open up the ports you need to open"?

I've only encountered one hotel network that denied everything except HTTP, 
but that has happened - and then we really are back to the land of 
[RFC3205].

Thanks,

Spencer

---

From: Dan York <[email-masked]>
Date: Thu, 14 Feb 2008 10:53:28 -0500

What I took from Jonathan's draft was the sense (correct in my view)  
that if we want new protocols to be successfully *deployed* in actual  
production networks and communicate across the firewall (which may or  
may not be doing NAT) to the public Internet, they should ideally sit  
on top of either TCP or UDP.

In both small and large corporate environments, my experience has  
certainly been that if you want communication to occur through the  
firewall, at some point you have to talk to "the firewall people".   
It may be one person or a team and they may have differing levels of  
paranoia about how tight of a ruleset they have, but they are there.   
And any new protocol needs to go through their box.

If you go to them and say that you need to open up TCP or UDP port  
XXX to/from a certain box, they may ask you questions, but at least  
they understand you. You are speaking their language.

If you go to them and say that you need to open up connections for a  
new transport protocol on top of IP, they will probably look at you  
like you have 3 heads.  And then they'll probably ask you a lot MORE  
questions.  And in fact they *may not be able to do it* with whatever  
firewall software they have.  I have seen some firewall software that  
when you are creating rules from the GUI, you only have 3 choices for  
a protocol on top of IP: TCP, UDP or ICMP.  Period. End of story.  If  
you want another transport protocol you *might* be able to do it with  
some command-line hackery, but that might also potentially be beyond  
the expertise level of the firewall people.

We can argue about how poorly designed that firewall software is, but  
that is the reality.  The deployed production environment on the  
public Internet today understands that transport protocols are TCP  
and UDP (with ICMP around to serve its limited purpose).

That is my take on Jonathan's point.

Want to have a successful protocol?  Want it to take off and  
(potentially) be adopted by millions?   Use TCP or UDP as the base.

My 2 cents,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Feb 2008 08:13:11 -0800

> You may not like it, but its reality.

Well, if we're talking about reality, why don't we talk about UDP?
UDP is an imperfect fit for NAT's and firewalls because it's stateless
and the stateful ALG needs to educe state from those packets. If
it's an protocol riding on top of UDP, the ALG is bound to get it wrong
at times.  Which as far as I've heard happens all the time. As in, UDP
is no panacea.

If you really want to put a stake in the ground here, it seems to me that
TCP is on a lot firmer ground. Why else would a lot of these IM protocols
and things like Skype use TCP fallback? It's because it's the only thing
that reliably works and they're not in the business of navel gazing about
whether they shouldn't do that because of its architectural ugliness.

More heresy: maybe we should work on hacks to TCP to allow it to
have non-reliable e2e delivery so that it was more friendly to real time
protocols built on top of it.

       Mike

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Feb 2008 11:14:34 -0500

> for policy reasons), we need to recognize that this is an arms race.

Thats why you need to separate it.

Running ontop of UDP and TCP means that your protocol can function 
through a NAT which exists for the purpose of NAT, regardless of 
firewall and administrative policy. And it means its in a format that 
your firewall vendor COULD manage policy for. It removes the TECHNICAL 
barriers to working on the Internet, leaving just the POLICY barriers.

Now, that doesn't address the problem of how we do a better job of 
managing those policy barriers. But one step at a time.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Feb 2008 11:19:26 -0500

inline:

Michael Thomas wrote:
>> all but NAT" trivialize what the Internet has evolved into. There is 
>> NAT everywhere. Lets accept it and design for what the Internet is, 
>> and not for the Internet as we wish it would be.
>>

True. Though if you do keepalives with some regularity (typically, 20 
seconds), it works in a lot of cases. Unfortunately, until recently 
there were no standards that defined what these timers should be. Now we 
have RFC 4787 which does define rules, but of course you cannot depend 
on the larger timers it recommends yet, since it has seen limited 
deployments.

> whether they shouldn't do that because of its architectural ugliness.

Absolutely. TCP is much more reliable. This is why ICE will probe for 
UDP and TCP and allow VoIP to fallback to TCP if there is no other 
choice. However, this is usually an artifact of firewall and not NAT; 
that part of it is an arms race.

> protocols built on top of it.

As you probably know folks absolutely have done this for exactly the 
reason you cite.

-Jonathan R.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 14 Feb 2008 11:38:20 -0500

First, I do agree that for operation through NATs, and even Firewalls, 
having the UDP header has been demonstrated to significantly simplify 
things, and is probably sensible.  (My earlier notes were prompted by a 
tone that said ~therefore all work we do should be over UDP or TCP. 
Always.~)

Lets not get carried away here though.  That does not solve the problem 
of operating through NATs.  I know that most folks in this conversation 
are well aware of this.  But the tone has started to sound like "do this 
and all will be well."  Which isn't even remotely the case.

I think that the key question that Jonathan's draft drives us towards is 
whether work like the SCTP / UDP draft Dan Wing pointed out needs to get 
more attention.  And soon.  It does seem to me that being able to run 
the applications which drove SCTP and DCCP over NATs is probably 
important.  And Jonathan (and others) observation that if the traffic 
isn't TCP or UDP it frequently won't get through NATs does seem to match 
observed reality.

Yours,
Joel M. Halpern

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 14 Feb 2008 08:38:40 -0800

As with most protocol design issues, this is a problem that becomes much
easier to deal with if there is a frank and realistic understanding of
the real world constraints.
 
While UDP or TCP are acceptable for virtually all protocol needs there
are many protocols for which they are not optimal.

In particular there are many cases where you would like to establish a
'lossy TCP connection'. That is you want the flow &ct. advantages that
you get from establishing a control channel session while accepting the
fact that in a real time connection you may well want to start dropping
packets that are arriving too late.

I think this can be done end-to-end in a manner that is entirely
backwards compatible. All we have to do (people are going to hate this)
is to eliminate the traditional assumption in TCP that a retransmitted
packet is going to be the same as the original, alternatively we can
eliminate the assumption that unacknowledged packets are going to be
retransmitted. That might well be the better approach.
 
A high level abstraction for a lossy connection will inevitably involve
additional overhead and additional programmer complexity. There has to
be a mechanism to allow the application layer.
 
The approach that comes to mind is to identify communication 'frames'
that are to be either transmitted in their entirety or lost. The high
level applications at the sending and receiving side need to know which
frames are transmitted, which are being lost and some indicator to show
if the delivery rate could be stepped up.

Lossy TCP should not be a problem for the Internet core since there is
never a guarantee that packets travel on the same path. There might be a
stateful inspection firewall that checks TCP sequence numbers but the
more usual concern is to control session initiation and teardown.

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dan York
Sent: Thursday, February 14, 2008 10:53 AM
To: Jonathan Rosenberg
Cc: Harald Tveit Alvestrand; Joel M. Halpern; [email-masked]
Subject: Do you want the protocol DEPLOYED or not? Re:
I-DAction:draft-rosenberg-internet-waist-hourglass-00.txt]

What I took from Jonathan's draft was the sense (correct in my view)
that if we want new protocols to be successfully *deployed* in actual
production networks and communicate across the firewall (which may or
may not be doing NAT) to the public Internet, they should ideally sit on
top of either TCP or UDP.

In both small and large corporate environments, my experience has
certainly been that if you want communication to occur through the
firewall, at some point you have to talk to "the firewall people".  It
may be one person or a team and they may have differing levels of
paranoia about how tight of a ruleset they have, but they are there.
And any new protocol needs to go through their box.

If you go to them and say that you need to open up TCP or UDP port XXX
to/from a certain box, they may ask you questions, but at least they
understand you. You are speaking their language.

If you go to them and say that you need to open up connections for a new
transport protocol on top of IP, they will probably look at you like you
have 3 heads.  And then they'll probably ask you a lot MORE questions.
And in fact they *may not be able to do it* with whatever firewall
software they have.  I have seen some firewall software that when you
are creating rules from the GUI, you only have 3 choices for a protocol
on top of IP: TCP, UDP or ICMP.  Period. End of story.  If you want
another transport protocol you *might* be able to do it with some
command-line hackery, but that might also potentially be beyond the
expertise level of the firewall people.

We can argue about how poorly designed that firewall software is, but
that is the reality.  The deployed production environment on the public
Internet today understands that transport protocols are TCP and UDP
(with ICMP around to serve its limited purpose).  

My 2 cents,
Dan

		While I disagree with Jonathan's assertion that we
should insert an 
		entirely useless (for all but NAT) UDP header in front
of all new 
		protocols we design,

	Well, I'd hardly characterize, "allowing it to work across the
public 
	Internet" as a property that is useless. Statements like,
"useless for 
	all but NAT" trivialize what the Internet has evolved into.
There is NAT 
	everywhere. Lets accept it and design for what the Internet is,
and not 
	for the Internet as we wish it would be.

	-Jonathan R.

	-- 
	Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
	Cisco Fellow                                   Edison, NJ 08837
	Cisco, Voice Technology Group
	[email-masked]
	http://www.jdrosen.net                         PHONE: (408)
902-3084
	http://www.cisco.com

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Feb 2008 08:50:44 -0800

> As you probably know folks absolutely have done this for exactly the 

No actually, I didn't know that... is this some kernel specific hacks to 
deal
with the head of line blocking problem? Or something else entirely?

       Mike

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 14 Feb 2008 19:05:30 +0100

Completely unrelated, what is the subject tag [dkim unverified]
supposed to do ?  Is that some joke in the spirit of RFC 4096 ?

As far as I can see it your mail from cisco.com got an SPF PASS
at core3.amsl.com, an unidentified agent claims to have seen a
DKIM PASS for [email-masked], and finally your mail arrived from
mail.ietf.org at GMane with SPF PASS.  Where is the problem ?

As always curious:

 Frank

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 14 Feb 2008 12:21:03 -0800

Joel M. Halpern wrote:

...
> I think that the key question that Jonathan's draft drives us
> towards is whether work like the SCTP / UDP draft Dan Wing pointed
> out needs to get more attention.  And soon.  It does seem to me that
> being able to run the applications which drove SCTP and DCCP over
> NATs is probably important.  And Jonathan (and others) observation
> that if the traffic isn't TCP or UDP it frequently won't get through
> NATs does seem to match observed reality.

I didn't provide a pointer to that SCTP/UDP draft to the list, and I 
noticed that just today a new DCCP/UDP draft was announced.  The 
two drafts are:

  "UDP Encapsulation of SCTP Packets"
  http://tools.ietf.org/html/draft-tuexen-sctp-udp-encaps

  "Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT
  Traversal (DCCP-NAT)"
  http://tools.ietf.org/html/draft-phelan-dccp-natencap

What seems useful is a mechanism where the UDP encapsulation can be
attempted and the native (non-UDP encapsulted) protocol can be
attempted.  In this way, the protocol can work through a skinny
hourglass (by running over UDP), yet if the path is unimpeded by
firewalls/NATs/proxies then the (more efficient) native encapsulation
can be used.

Where DNS can be used as the rendezvous protocol, DNS SRV might
provide a way to accomplish such a thing, where you could learn that
there is a UDP-encapsulated port and a native (non-UDP encapsulation)
protocol to a host.  The application and/or the underlying SCTP/DCCP
stack could try both, in some agreed-upon order and with agreed-upon
backoff mechanisms.

Such a mechanism is what ICE, draft-ietf-mmusic-ice, performs in its
attempts to get v4, v6, UDP, or TCP connectivity.  ICE needs a
rendezvous protocol that includes an offer/answer exchange, such as
SIP, RTSP 2.0, or XMPP.

-d

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 14 Feb 2008 21:28:57 +0100

On 14 feb 2008, at 21:21, Dan Wing wrote:

> attempted.

I was thinking along similar lines. Notwithstanding what I said  
earlier, sometimes encapsulating something in UDP to make it pass  
through whathever needs passing through can be useful. For instance,  
there have been one or two occasions where I could have used IPv6 in  
UDP encapsulation but without all the baggage that comes with Teredo.

But it seems to me that a much better approach to this is first of all  
to make it optional, like you suggest, and secondly, make it a generic  
mechanism that can be used for ALL protocols rather that define it  
separately for one protocol at a time.

In essence, something like this would increase the address lenght by  
16 bits.
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Florian Weimer <[email-masked]>
Date: Thu, 14 Feb 2008 21:49:20 +0100

> becomes more widely deployed?

The prevailing assumption is that IPv6 end nodes will be globally
addressable for practical purporses.  I think this is a very unlikely
outcome.

Section 4 in the draft may be common knowledge, but often deliberately
ignored during protocol design because "it's not the way the Internet
works" (or some other reason remotely derived from rather general
policies).

(BTW, the draft should be a bit clearer about the new waist's properties
-- only very specific traffic patterns are widely NAT-compatible.)
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 14 Feb 2008 22:04:00 +0100

Dear all,

just a comment inline.

Best regards
Michael

> header" in their checksum computation to date, and I have seen no  
SCTP does NOT use a pseudo IP header for its checksum calculation.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Feb 2008 23:05:45 +0200

The actual encoding of the packets into UDP is the simple part.
The difficult part is to get the rest to work since you have to combine 
it with a protocol that offers the end-to-end connectivity and to get 
the rest to work.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 14 Feb 2008 22:16:18 +0100

> addressable for practical purporses.  I think this is a very unlikely

Are you saying that there will be IPv6 NAT?

And that we should design protocols running on top of IPv6 to take NAT  
into account?

If yes on both, how can we do that without a NAT specification so that  
the IETF can design protocols to work with NAT and vendors can build  
NATs that work with IETF protocols?

I.e., either we assume no NAT in IPv6, or create a NAT standard. Those  
are the only sane options.
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: jewheele <[email-masked]>
Date: Thu, 14 Feb 2008 13:21:15 -0800

Ralph
Have you been following this thread?  What odd questions and
assumptions...appears as if folk have no idea re: IPv6 addressing ..all end
nodes will be globally addressable for 'practical purposes' is such an odd
statement to make...either:
1.  meaning that all end nodes will have globally unique and addressable
addresses; or
2.  that all end nodes will 'automagically' be able to be reached through
the IPv6 routing and routed protocols.

Obviously #2 is sound but probably not what this person meant...

Cute...

jeff

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Feb 2008 16:24:38 -0500

> separately for one protocol at a time.

Protocol options are bad. Especially ones like this which are quite hard 
to negotiate. What the draft is saying, is just design the darn thing to 
work only over UDP, rather than natively over IP. It'll work on the v4 
Internet and in the v6 Internet too. Odds are good your protocol needed 
ports and a checksum anyway. So what exactly is this 'baggage'?

> In essence, something like this would increase the address lenght by  

Well, as I am sure you know, the reason NAT is so successful is that it 
basically does extend the IP address space by 16 bits, but in a 
backwards compatible way, making it incrementally deployable. Thus, you 
get high utility and ease of deployment, the double whammy that leads to 
success, as draft-iab-protocol-success discusses.

-Jonathan R.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 14 Feb 2008 22:36:01 +0100

On 14 feb 2008, at 22:24, Jonathan Rosenberg wrote:

>> But it seems to me that a much better approach to this is first of  
>> all  to make it optional, like you suggest, and secondly, make it a  
>> generic  mechanism that can be used for ALL protocols rather that  
>> define it  separately for one protocol at a time.

> Protocol options are bad. Especially ones like this which are quite  
> hard to negotiate. What the draft is saying, is just design the darn  
> thing to work only over UDP, rather than natively over IP. It'll  
> work on the v4 Internet and in the v6 Internet too. Odds are good  
> your protocol needed ports and a checksum anyway. So what exactly is  
> this 'baggage'?

If the protocol needs this stuff anyway, no problem. But for the  
current non-TCP, non-UDP protocols, that doesn't help. Remember the  
computer science adage: put all your eggs in one basket, but make it a  
very good basket. A genereric mechanism to negotiate UDP encapsulation  
for all protocols where desired would find wide deployment and thus  
work well while revisiting every protocol just means having the same  
headache many times over.

The problem that I have with your draft is that you seem to want to  
forbid new non-TCP, non-UDP protocols. If a protocol doesn't need port  
numbers or a UDP-like checksum (i.e., either no checksum or a better  
one) then it's a bad thing to just add a UDP header for the hell of  
it. Especially as overhead keeps growing but MTUs stay the same.

I can envision many cases where UDP encapsulation is useful in IPv4 to  
get around NAT but it's not necessary in IPv6.
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Dan York <[email-masked]>
Date: Thu, 14 Feb 2008 17:12:36 -0500

> Are you saying that there will be IPv6 NAT?

Absolutely.  100% guaranteed that some organizations out there will  
continue to use NAT even with IPv6.

In my opinion, anyone who thinks otherwise does not understand how  
wedded corporate enterprises are to NAT and how NAT will only be  
removed when the keyboard is pulled from the cold, dead fingers of  
the last remaining sysadmins.

Instead of the "private addresses" of IPv4 as defined in RFC1918 it  
will simply be the "Unique Local Addresses" of IPv6 as defined in  
RFC4193 - http://tools.ietf.org/rfcmarkup?doc=rfc4193  Instead of  
starting with 10. (or 192. or 172.), the address block will start  
with FC00... but the end result will be the same.  (And look, this  
time around it even has it's own TLA ("ULA")!)

Corporate enterprises love NAT for several reasons. Here are two:

1. "SECURITY" - There is this belief that an organization is more  
secure by hiding the topology of their entire network behind a few  
public addresses that can be locked down and secured by appropriate  
firewalls and gateways.  IT staff don't give a darn about our  
glorious visions of end-to-end connectivity... they only care about  
"securing the perimeter" and many (most?) see NAT as one way of doing  
that.  We can argue endlessly that this may simply be an illusion  
(delusion?) on their part and that NAT really doesn't provide real  
security, but from what I have seen it *is* the prevailing view out  
there within the IT community.

2. CONTROL - Organizations like the control that comes with defining  
their own address ranges.  They don't need to obtain permission from  
anyone to number certain networks.  They just do it.  Simple. Easy.   
They can create a master plan across all their locations on their  
WAN.  As they add more networks through growth (either new  
installations or through mergers/acquisitions), they can simply  
assign those new networks numbering blocks out of their master plan.   
In fact, I would argue that ULA addressing (there I go with that  
TLA!) makes that even nicer since the recommended means of generation  
of the ULA block (in RFC4193) *should* wind up reducing the conflicts  
we have today where merging entities are both using identical  
sections of the RFC1918 10.x block. In theory the networks should be  
even easier to merge.  Likewise, if a network gets split off from  
another one, it may be able to be merged into its new owner very  
easily (and without renumbering) via ULA addressing.

In this last instance, think of what happens if I'm using assigned  
IPv6 addresses from Company A and now my network is sold to Company  
B. Now I have to renumber my entire network to use Company B's  
assigned IPv6 addresses.  If I just use ULA addressing I don't have  
to renumber (unless by some freak chance I happen to be using the  
same ULA block that some other network in Company A is using).

So yes, I absolutely think that NAT will continue in IPv6.  Corporate  
enterprises are comfortable with it and expect it.  That's the reality.

> And that we should design protocols running on top of IPv6 to take NAT

Yes.

> NATs that work with IETF protocols?

Good question.

> are the only sane options.

Agreed.

My 2 cents,
Dan

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 15 Feb 2008 08:06:16 +0900

> continue to use NAT even with IPv6.

Just as NTT is already using closed IPv6 network for their NGN-like
service, mobile telephone operators will use closed IP networks,
which will be connected to the Internet through NAT or something
like that.

						Masataka Ohta

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 14 Feb 2008 23:36:19 +0530

> retransmitted. That might well be the better approach.

Many years ago I implemented an even simpler approach to "lossy TCP":

When sending a packet (most higher level protocols have packets), check how 
full the sending buffer (which retains a copy of all unacknowledged data) 
is; if it's "rather full", and the packet is "not important", throw it away.

Worked like a charm. And no redefinitions of TCP semantics required at all.

                     Harald

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 13 Feb 2008 08:30:17 -0800

> - "well, if we all know this, what are we doing differently now that we know 

	How not to have this happen in ipv6?

---

From: Stjepan Gros <[email-masked]>
Date: Fri, 15 Feb 2008 10:06:36 +0100

On Thu, 2008-02-14 at 17:12 -0500, Dan York wrote:
> removed when the keyboard is pulled from the cold, dead fingers of the
> last remaining sysadmins.
> 
> 
> starting with 10. (or 192. or 172.), the address block will start with
> FC00... but the end result will be the same.  (And look, this time
> around it even has it's own TLA ("ULA")!)
> 
> 
> firewalls and gateways.  IT staff don't give a darn about our glorious
> visions of end-to-end connectivity... they only care about "securing
> the perimeter" and many (most?) see NAT as one way of doing that.  We
> can argue endlessly that this may simply be an illusion (delusion?) on
> their part and that NAT really doesn't provide real security, but from
> what I have seen it *is* the prevailing view out there within the IT
> community.
> 
> 
> installations or through mergers/acquisitions), they can simply assign
> those new networks numbering blocks out of their master plan.  In
> fact, I would argue that ULA addressing (there I go with that TLA!)
> makes that even nicer since the recommended means of generation of the
> ULA block (in RFC4193) *should* wind up reducing the conflicts we have
> today where merging entities are both using identical sections of the
> RFC1918 10.x block. In theory the networks should be even easier to
> merge.  Likewise, if a network gets split off from another one, it may
> be able to be merged into its new owner very easily (and without
> renumbering) via ULA addressing.
> 
> 
> IPv6 addresses from Company A and now my network is sold to Company B.
> Now I have to renumber my entire network to use Company B's assigned
> IPv6 addresses.  If I just use ULA addressing I don't have to renumber
> (unless by some freak chance I happen to be using the same ULA block
> that some other network in Company A is using).
> 
> 

All that said, what happens when organizations would like to use multihoming?
In that case NATs create problems as flows have to use the same
exit/entry point, and when one of the connections breaks all the flows
going through the given connection will also be broken?

How is this problem solved in current IPv4 networks?

Thanks,
Stjepan

---

From: Lars Eggert <[email-masked]>
Date: Fri, 15 Feb 2008 15:10:45 +0200

Hi,

I enjoyed reading your draft, and I'm looking forward to discussing it  
in Philly. (We've asked Jonathan if he'd present at TSVAREA or INTAREA.)

> found the entire conversation surreal.

A big driver for SCTP was for use a signaling protocol. Other SDOs are  
using SCTP for signaling in their network architectures, and are also  
now introducing NAT functionality at controlled places in these  
architectures. This is why I believe and have argued that an IETF BCP  
that documents how to correctly NAT SCTP is the right thing to  
produce. (And, FWIW, DCCP. There's some interest in that as well, but  
not such an immediate one as for SCTP.) As a SIP-area person, this  
mode of operation should be familiar to you.

Will this BCP make SCTP available behind a home NAT? Nope. But it  
provides a specification that people can refer to who design network  
architectures that are more tightly controlled than the end user  
Internet, i.e., where people can define and then require their NATs to  
have this functionality.

Lars

---

From: Dan York <[email-masked]>
Date: Fri, 15 Feb 2008 09:35:41 -0500

Remi,

On Feb 15, 2008, at 5:23 AM, Rémi Després wrote:

> Dan York wrote :

Just to be clear, that particular text was written by Iljitsch van  
Beijnum, although I agree with him on it.

> Somehow it can be both, but NOT at the same time :
>
> In the IPv6-only world, to be reached at the end of the transition  
> period, NATs should IMO be prohibited.

I think we will have to respectfully disagree on this one.  Count me  
in the camp that says that NAT will *NEVER* go away as long as  
corporate enterprises believe it is of value to them (as I noted in  
my previous message).  Even were we to somehow "prohibit" it,  
enterprises would still do it... or our stance on prohibiting it  
would simply be yet another barrier for them to seriously consider  
moving to IPv6.

NAT is here. NAT is loved (by many). NAT will be with us until long  
after we are all long gone.

The question is whether we standardize how NAT is done with IPv6 or  
whether we just let the vendors go wild with it as they did for IPv4.

My 2 cents,
Dan

---

From: Paul Francis <[email-masked]>
Date: Fri, 15 Feb 2008 09:44:28 -0500

I wonder if standard approaches to NAT for IPv6 just isn't going to be much
of an issue even if the IETF ignores it.  Since NAT for IPv6 is much simpler
than for IPv4, a bunch of the issues associated with IPv4 NAT usage don't
exist.  Like, there should be no need for port translation.  No need to time
out mappings.  For the most part, NAT for IPv6 should be just a simple
substitution of prefix A for prefix B.  What, exactly, are the range of
choices that NAT vendors need to agree on?

PF

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dan York
> Sent: Friday, February 15, 2008 9:36 AM
> To: Rémi Després
> Cc: [email-masked]
> Subject: Re: IPv6 NAT?
> 
> Remi,
> 
> Just to be clear, that particular text was written by 
> Iljitsch van Beijnum, although I agree with him on it.
> 
> 
> 	In the IPv6-only world, to be reached at the end of the 
> transition period, NATs should IMO be prohibited.
> 
> 
> I think we will have to respectfully disagree on this one.  
> Count me in the camp that says that NAT will *NEVER* go away 
> as long as corporate enterprises believe it is of value to 
> them (as I noted in my previous message).  Even were we to 
> somehow "prohibit" it, enterprises would still do it... or 
> our stance on prohibiting it would simply be yet another 
> barrier for them to seriously consider moving to IPv6.
> 
> NAT is here. NAT is loved (by many). NAT will be with us 
> until long after we are all long gone.
> 
> The question is whether we standardize how NAT is done with 
> IPv6 or whether we just let the vendors go wild with it as 
> they did for IPv4.
> 
> My 2 cents,
> Dan
> 
> --

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 15 Feb 2008 08:51:12 -0600

For a fairly good discussion on NAT and IPv6, see:

   ftp://ftp.rfc-editor.org/in-notes/rfc4864.txt

--
Eric Gray
Principal Engineer
Ericsson  

> Behalf Of Paul Francis
> Sent: Friday, February 15, 2008 9:44 AM
> To: Dan York; Rémi Després
> Cc: [email-masked]
> Subject: RE: IPv6 NAT?
> 
>

---

From: <[email-masked]>
Date: Fri, 15 Feb 2008 15:09:15 -0000

> Since NAT for IPv6 is much simpler than for IPv4, a bunch of 
> the issues associated with IPv4 NAT usage don't exist.  Like, 
> there should be no need for port translation.  No need to 
> time out mappings.  For the most part, NAT for IPv6 should be 
> just a simple substitution of prefix A for prefix B.  What, 
> exactly, are the range of choices that NAT vendors need to agree on?

A couple of things come to mind... 

Vendors need to agree on the timeout for mappings and on the
method for substituting prefixes. Even if ignoring port translation
seems obvious, a vendor who is adapting/upgrading old code might
include this in the absence of a standard. Also, an IPv6 NAT could
include features that are not in v4 NAT such as using RFC 3041
algorithms to generate the Interface ID portion of the mapped 
address rather than passing the ID through unchanged.

An often used example of how IPv6 is better than IPv4, talks about
how every device can have its own IPv6 address, so that just like
a telephone set, every device can be "called" by any other device.
But if you look into how the telephone system works, many telephone
sets are not available to receive calls. Instead, they are in
communication with a PABX which may or may not forward phone calls
to the phone set. Since an IPv6 NAT device fills an analogous gateway
role in the Internet, one wonders why there is no IPv6 NAT standard
to cover things like local hosts registering with the NAT to receive
packets on a certain port, or local hosts registering a forwarding
address for packets on a certain port.

--Michael Dillon

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 15 Feb 2008 07:23:51 -0800

OK, yes that will lag for the first few packets after a change in transmission rate but quickly converge on my proposal. The rate of convergence will depend on the adaptation algorithm.
 
Since my lossy TCP is essentially congruent to what folk are trying to get out of UDP here it appears that the problem is due to the sockets layer not exposing sufficient information to the application layer. We can fix this at the sender end point. 
 
We don't need a new protocol, all we need to do is to accept the fact that some parts of the Internet as deployed are easier to change than others and build a deployment strategy accordingly.

From: Harald Tveit Alvestrand [mailto:[email-masked]]
Sent: Thu 14/02/2008 1:06 PM
To: Hallam-Baker, Phillip; Dan York; Jonathan Rosenberg
Cc: Joel M. Halpern; [email-masked]
Subject: RE: Do you want the protocol DEPLOYED or not? Re: I-DAction:draft-rosenberg-internet-waist-hourglass-00.txt]

                     Harald

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 15 Feb 2008 16:30:15 +0100

On 15 feb 2008, at 16:09, <[email-masked]> wrote:

> include this in the absence of a standard.

With 1-to-1 address translation without the port overloading the  
mappings can be static so there is no need for timeouts. And incoming  
connections can be translated just as easily as outgoing connections.

One wonders whether the pro-NAT crowd would actually like something as  
open as that. Then again, emulating IPv4 NAT behavior just because  
it's the devil we know even though it would require a significant  
effort to create IPv6 versions of ALGs and then it would still get in  
the way of legitimate applications a whole lot isn't all that  
attractive, either.
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 15 Feb 2008 07:47:00 -0800

Consider the case where my home network is IPv6, my broadband provider is IPv4 only and the box I am ultimately contacting is IPv6.
 
There you have an IPV6 NAT box, its called the legacy IPv4 Internet and its going to be around for at least as long as Telex survived after the invention of email.

From: [email-masked] on behalf of Iljitsch van Beijnum
Sent: Fri 15/02/2008 10:30 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: IPv6 NAT?

---

From: Lars Eggert <[email-masked]>
Date: Fri, 15 Feb 2008 17:53:01 +0200

Hi,

> packets that are arriving too late.

you're not the first one to have that idea. Which is why there is DCCP.

And you're going to say that that doesn't work because it uses a  
different protocol number, but if you are going to reuse protocol 6  
for "lossy" TCP, you are going to need a flag somewhere that lets a  
receiver differentiate between standard and "lossy" TCP. What you're  
proposing is DCCP with that flag somewhere other than the protocol  
number, or any other field that NATs have assumptions about.

> packet is going to be the same as the original,

There is no such assumption in TCP. A hole in the sequence number  
space can be filled through any combination of retransmissions.

> alternatively we can

And that's what DCCP does.

> be a mechanism to allow the application layer.

There is a piece of this sentence missing, but anyhow, DCCP has  
realized this and is working on a "user guide" that would tell app  
implementers about how to use the protocol.

> if the delivery rate could be stepped up.

You might want to read RFC4340.

> more usual concern is to control session initiation and teardown.

Few things are a problem for the core, but there's a ton of  
middleboxes at the edge that have assumptions about what TCP should  
look and act like. Things aren't as simple as using protocol number 6  
with something that sort of looks like a TCP header.

Lars

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 15 Feb 2008 09:55:24 -0600

Well, accepting incoming IPv6 connections(!) through NATs would turn the 
incoming-connection question from a technical issue into a 
firewall-policy-only issue...

I'm with Dan that I don't see NATs disappearing in IPv6 - I remember in the 
early days of the NAT working group (back when we thought our opinion about 
NATs mattered) that someone got up and said their company had been audited, 
and the auditors asked where the NATs were - apparently, this was (at that 
time, at least) on audit checklists, and you got dinged if you weren't using 
NATs, even if you were using firewalls (and even if you were using host OSes 
that didn't roll over every time there was a virus outbreak, but I digress).

I'd love for that to change, but whether people agree about desirability or 
not, we can all agree that it would be a change, I think.

Spencer

From: "Iljitsch van Beijnum" <[email-masked]>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 15 Feb 2008 08:11:37 -0800

Yes, I know that people have tried to deploy new schemes beyond TCP and UDP.
 
DCCP has one major difference, it is not designed for deployment and so as far as I am concerned it might as well not exist. Like multicast this is a transport optimization. A transport optimization has precisely zero interest to me unless it is going to interoperate with 100% of the systems I might want to connect to.

Harald's proposal is elegant and has minimum impact on the infrastructure. That is the type of proposal that I like and would want to see supported.
 
Proposing new protocol numbers may have some interest in large walled garden infrastructures, particularly if you want to make the transition from walled garden to Internet somewhat costly for lock in purposes. But its a dead end unless you have a really powerful killer application that can build out the infrastructure for you.

From: Lars Eggert [mailto:[email-masked]]
Sent: Fri 15/02/2008 10:53 AM
To: Hallam-Baker, Phillip
Cc: Dan York; Jonathan Rosenberg; Harald Tveit Alvestrand; Joel M. Halpern; [email-masked]
Subject: Re: Do you want the protocol DEPLOYED or not? Re: I-DAction:draft-rosenberg-internet-waist-hourglass-00.txt]

Hi,

Lars

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 15 Feb 2008 08:12:53 -0800

You know of an O/S that is not vulnerable to malware attacks? Please let me know the name, I haven't encountered one professionally since I was using OpenGenera in '95 and that was only secure because we had a more or less complete list with the names of every person who had ever successfully managed to learn the beast.

There is a way we could change security audit requirements, but it would involve rather more flexibility in approach than the IETF has been willing to accept. We would have to talk to the auditors and provide them with alternative means of achieving the ends that they consider important, not try to argue with the importance of those ends.

From: [email-masked] on behalf of Spencer Dawkins
Sent: Fri 15/02/2008 10:55 AM
To: Iljitsch van Beijnum; [email-masked]
Cc: [email-masked]
Subject: Re: IPv6 NAT?

Spencer

---

From: Christian Huitema <[email-masked]>
Date: Fri, 15 Feb 2008 09:37:41 -0800

> You know of an O/S that is not vulnerable to malware attacks? Please let me know
> the name, I haven't encountered one professionally since I was using OpenGenera
> in '95 and that was only secure because we had a more or less complete list with
> the names of every person who had ever successfully managed to learn the beast.

Very few software products can be considered perfect. However, NAT and basic statefull firewalls only protect against a specific category of attacks, the arrival of unsolicited connection requests through the network. Most mainline operating systems have built-in protection against such attacks. Windows XP-SP2 and Windows Vista certainly do. They come with a built in firewall that will, by default, prevent incoming traffic on all ports. I understand that recent Linux distributions and recent versions of OS/X have similar protections.

Attacking ports by sending random packets is very much a 2003 story. Modern malware typically works by exploiting users' naiveté, bugs in document parsers, or a combination of both. An example of user naiveté would be to ask users to download a special media player to look at frolicking bodies. An example of exploiting document parsers would be to lure users to visit a malevolent web site, and have they open a booby trapped image or movie.

The typical NAT or stateful firewall offers no protection against document parsing bugs. That is a good thing. If firewalls tried to do that, they would have to incorporate a large amount of document parsing code, and would most probably become a target for their own parsing bugs. Of course, no amount of electronics will protect against users intent on downloading a very special media player...

-- Christian Huitema

---

From: <[email-masked]>
Date: Fri, 15 Feb 2008 18:10:33 -0000

>	Consider the case where my home network is IPv6, my broadband
provider 
> is IPv4 only and the box I am ultimately contacting is IPv6.
	 
>	There you have an IPV6 NAT box, its called the legacy IPv4
Internet 
>and its going to be around for at least as long as Telex survived after

>the invention of email.

The first email message that I sent was in 1974 but I believe it was
around
earlier than that. Here in the UK, BT plans to shut down the Telex
network
by next month, March 2008 according to
<http://www.sinet.bt.com/331v2p1.pdf>

It is becoming increasingly clear that we are not in a transition to
IPv6,
but in a transition to IPv4-IPv6 coexistence and interoperation. It's
messy
but that is what is coming down the road.

--Michael Dillon

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 15 Feb 2008 11:43:45 -0800

> Sent: Friday, February 15, 2008 6:44 AM
> substitution of prefix A for prefix B. 

Such 1-for-1 address rewriting does not provide the topology 
hiding that many people seem to like of their existing NAPT
devices, nor does such 1-for-1 address rewriting obscure the
number of hosts behind the NAT.  Such obscuring can be useful
for certain businesses (there are, today, small ISPs in certain
countries that do not want their country's PTT to know the
ISP's actual market share, for fear tarrifs or advertising to
compete with the small ISP will be increased).

-d

> What, exactly, are 
> the range of

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 15 Feb 2008 20:50:12 +0100

> compete with the small ISP will be increased).

So how far, exactly, are you prepared to bend over backwards and crack  
the spine of the IP architecture to accommodate 0.01% or so of its  
users? Not to mention the cost increases for all the extra protocol  
layers and debugging that must be borne by the other 99.99%?

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 15 Feb 2008 11:56:41 -0800

...
> to the phone set.

Another example were pay phones which did not have their incoming
number published, or were disabled from accepting incoming calls.
This was especially common in areas where criminal activity was
associated with such incoming calls (most commonly the sale and
distribution of illegal drugs or prostitution).  Since then many
of these pay phones have since been de-installed (for various
reasons) and such criminal activity has moved to pre-paid 
cellular phones.

> Since an IPv6 NAT device fills an analogous gateway

Network address translation is not necessary to enforce such
restrictions -- a firewall is adequate.  For the specific 
requirements listed in your sentence above, a host firewall
would even be sufficient.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 15 Feb 2008 12:12:34 -0800

> layers and debugging that must be borne by the other 99.99%?

I am not willing to bend over backwards or even sideways for 
such numbers.

-d

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Feb 2008 17:49:35 -0500

inline:

> layers and debugging that must be borne by the other 99.99%?

Its not for me or you to decide. The issue is, will the people who 
operate these networks decide that they want NAT. And then it is for 
IETF to decide about whether they would like to engineer protocols that 
actually work on the networks that those administrators have built.

A big mistake was made in IPv4, where NAT was declared 'evil' and we 
didn't spend enough time defining it well. Now, it is wildly successful 
and a part of what the Internet is, and it is harder to deal with it. 
Had we done standards work up front and early, and defining exactly how 
NAT work, things would work much better. We should have had RFC4787 in 
1997 and NOT 2007.

And now, we face the same dilemma with IPv6. Do we continue to deny the 
possibility of IPv6 NAT? Do we decide NOT to standardize it? Have we not 
learned our lesson from the first time around?

So, I think it would be good to define IPv6 NAT behavior, and do so NOW 
before its too late, and define it in a way that it would appeal to the 
admins that have deployed IPv4 NAT today. Worst case, it doesn't get 
used and we have this nice utopian NAT-free IPv6 network. Can you say 
the same for the worst-case situation for NOT standardizing v6 NAT?

-Jonathan R.

"Insanity: doing the same thing over and over again and expecting 
different results."
--Albert Einstein

---

From: David Kessens <[email-masked]>
Date: Fri, 15 Feb 2008 15:27:07 -0800

Jonathan,

> NAT work, things would work much better. We should have had RFC4787 in 

NATs are *not* on the wire protocols but middleboxes that break havoc
with peer-to-peer applications but that help to get people that don't
have enough IP addresses to use or have reasons why they cannot do a
network renumbering. For interoperability, there is no necessity for
all NATs to work in exactly the same way, hence the incentive for
anybody to follow a standard would be rather low. If we had defined
NAT in 1997, it would have been obsoleted before it had even reached
the RFC editor as competition in the marketplace would have forced
vendors/open source community to leap frog each other with small and
big improvements over the IETF standard. The only useful role for IETF
would have been and still is to provide some beHAVIORal advice on what
we have observed as a common lowest denominator between the different
implentations.

There is nothing special about NATs, we know what problems they cause,
we know what problems they solve. We even have relatively simple
protocols that can traverse them. Observations that it is hard to
deploy new transport protocols are not exactly very new either and it
is quite obvious that NATs are part of the story why deploying anything
new on the Internet has become much harder. Can we perhaps move on to
a topic that involves new insights or ideas ?

David Kessens
---

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 16 Feb 2008 14:16:34 +0100

On 15 feb 2008, at 23:49, Jonathan Rosenberg wrote:

>> So how far, exactly, are you prepared to bend over backwards and  
>> crack  the spine of the IP architecture to accommodate 0.01% or so  
>> of its  users? Not to mention the cost increases for all the extra  
>> protocol  layers and debugging that must be borne by the other  
>> 99.99%?

> IETF to decide about whether they would like to engineer protocols  
> that actually work on the networks that those administrators have  
> built.

A much better course of action is to agree on what is a reasonable use  
of IP technology first so that everyone can build stuff that works  
together from the start without undue cost or inconvenience, rather  
than having to go through a large number of frustrating iterations  
where new protocols can't be deployed because middleboxes don't let  
them through and middlebox buyers are unhappy with their vendors  
because the middlebox gets in the way of certain stuff.

> didn't spend enough time defining it well. Now, it is wildly  
> successful and a part of what the Internet is, and it is harder to  
> deal with it. Had we done standards work up front and early, and  
> defining exactly how NAT work, things would work much better.

Sure, but still much worse than without NAT. NAT IS evil in the sense  
that it makes life a lot harder, that's not the question. The question  
is whether it's a necessary evil. And that question is moot for IPv4  
now, it's no longer possible to have a NAT-free IPv4 network. But it  
IS possible to have a NAT-free IPv6 network, although the requirement  
to change addresses often as external connectivity changes is deemed  
problematic by some. A NAT that only addresses this issue (i.e.,  
static 1-to-1 address mappings where internal and external addresses  
have the same checksums so it's transparent to all protocols except  
those that do referrals) might not be too evil, but an IPv4-style port  
overloading NAT is even more evil in IPv6 because the workaround code  
isn't there in IPv6, and it's not a necessary evil either, because  
there is an abundance of address space in IPv6.

> And now, we face the same dilemma with IPv6. Do we continue to deny  
> the possibility of IPv6 NAT? Do we decide NOT to standardize it?  
> Have we not learned our lesson from the first time around?

What type of IPv6 NAT would you like to standardize?
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Rémi Després <[email-masked]>
Date: Fri, 15 Feb 2008 11:23:39 +0100

Dan York wrote :

I.e., either we assume no NAT in
IPv6, or create a NAT standard. Those

- IPv6 firewalls should take care of all the security issues.

- They should not interfere with end-to-end significance of IPv6
addresses and port numbers.

NATs will be needed during the (long) transition period, including some
NATs dealing with both IPv6 and IPv4.

Their standardization is desirable at least for:

- IPv4-only client hosts in sites that have only IPv6 prefixes (i.e.
clients with private IPv4 addresses in sites without IPv4 addresses).

- IPv6-only hosts that reach IPv4-only servers (clients without IPv4
addresses reaching servers without IPv6 adresses).

Regards.

Rémi

---

From: Rémi Després <[email-masked]>
Date: Fri, 15 Feb 2008 18:41:12 +0100

Dan York wrote :
> I think we will have to respectfully disagree on this one.  Count me in 
> the camp that says that NAT will *NEVER* go away as long as corporate 
> enterprises believe it is of value to them (as I noted in my previous 
> message).  Even were we to somehow "prohibit" it, enterprises would 
> still do it... or our stance on prohibiting it would simply be yet 
> another barrier for them to seriously consider moving to IPv6.
> 
I agree that many love NATs.
But that's the existing ones, private v4 to public v4.

I guess that they will also love some king of v6-v4 NATs, the ones we DO 
NEED to standardize.

Regarding v6-v6 NATs, the word "prohibit", I must accept it, was not 
well chosen. (There is no way, nor is there any intent to check what 
people do in private premises.)
The point is rather that IMHO there will be better ways to achieve the 
same privacy and security functions that NATs happen to offer.

Here is such an other way: if a client host takes a new randomly chosen 
"privacy IID" for each of its outgoing connections: (1) its address and 
its chosen port will keep their E2E significance; (2) no one will know 
where it is in its site; (3) any attempt to call such an address will 
fail; (4) the host will easily clean up its state when it knows a 
connection is finished, or when it resets, or when its power is turned 
off; (5) no stateful logic is needed in any intermediate box; (6) 
intermediate boxes are not concerned with protocols used (UDP, TCP, 
SCTP...).

Reagards.

Rémi

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 17 Feb 2008 08:48:22 -0800

> success, as draft-iab-protocol-success discusses.

So this thread could be summarized as "32+16 > 128"

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 17 Feb 2008 22:05:20 +0100

> NATs will be needed during the (long) transition period, including  
> some NATs dealing with both IPv6 and IPv4.

I don't see how the transition from IPv4 to IPv6 requires NAT in IPv6.

One of the downsides of the NAT-PT mechanism is that it exposes hosts  
that think they're doing IPv6 to (IPv4-) NAT. However, by making the  
IPv6 hosts aware of the fact that they're talking to an IPv4 host,  
they can apply their NAT handling code to IPv4 only (even if it's  
translated IPv4) and be NAT-free when doing actual IPv6.

Apart from that, we have a long tradition of temporary things becoming  
permanent. You can't unring a bell, cat's won't be herded back into  
the bag or worms back in the can etc.
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Feb 2008 13:01:28 +1300

On 2008-02-15 22:06, Stjepan Gros wrote:
...
> How is this problem solved in current IPv4 networks?

It isn't. That's one of the reasons why NAT causes undiagnosable
session disconnects.

> choices that NAT vendors need to agree on?

Exactly. In other words the hardest issues that NATv4 hits simply don't arise in
IPv6, which I believe is isomorphic with the statement that NAT is logically
unnecessary in IPv6 (and that's why we wrote RFC 4864, to show how the
*perceived* benefits of NAT beyond address sharing can be provided
without NAT). Dan Wing is of course correct that this won't automatically
stop corporate IT folk asking for NAT.

On 2008-02-16 04:09, [email-masked] wrote:

> Vendors need to agree on the timeout for mappings 

As Paul observed, no timeout is needed (as long as the
untranslated address remains valid).

> and on the
> method for substituting prefixes. 

Since this is a local operation, why is there anything
to standardise?

Even if ignoring port translation
> address rather than passing the ID through unchanged.

It could, but all that is pointless - the host itself can use RFC 3041
if it wants. Why invent work for an unnecesary box?

> address for packets on a certain port.

Because that has nothing to do with NAT. Those functions, if you
want them, are firewall functions.

On 2008-02-16 11:49, Jonathan Rosenberg wrote:
...
> admins that have deployed IPv4 NAT today.

That's a terrible idea, because it would pander to the myths that
NAT is a security or policy tool. I think Paul Francis' comment
shows that there is almost nothing to define, and that if we
write anything, it should be absolutely minimal, and contain appropriate
MUSTs and MUST NOTs for all the things that should be done
differently in IPv6.

> Worst case, it doesn't get 
> used and we have this nice utopian NAT-free IPv6 network. 

No, that's the best case. The worst case is that it encourages vendors
to implement it and corporate IT folk to deploy it.

> Can you say 

That's a very hard question to answer, because it depends very much
on how CPE and firewall vendors react in their product plans. Since they
all know that NAT isn't needed for IPv6, and product managers are not
known for funding unnecessary work, in the best case, it doesn't get
implemented. In the worst case, it gets implemented randomly.

    Brian

---

From: Terry Gray <[email-masked]>
Date: Sun, 17 Feb 2008 17:30:41 -0800 (Pacific Standard Time)

> NAT is a security or policy tool.

Brian,
Several comments in this thread have suggested that security is the 
primary driver for NAT.

While it is surely a factor, I believe the dominant driver for NAT is 
addressing autonomy.

Unless/until enterprise (or even home) network operators have some 
number of bits of address to call their own, without risk of forced 
change or being held hostage to their ISP, you will have NAT for v6 
just like for v4.  I think you can take that to the bank.

(Note that autoconf doesn't remove this need... enterprise operators 
will have local host addresses sprinkled throughout a plethora of 
departmental traffic disruption appliances, so renumbering will be 
viewed by many as a non-starter.)

-teg

---

From: Mark Andrews <[email-masked]>
Date: Mon, 18 Feb 2008 13:48:41 +1100

> just like for v4.  I think you can take that to the bank.

	They have that today without NAT.   You are stuck in IPv4
	think.  You are thinking *one* address per interface.
	IPv6 was designed with *multiple* addresses per interface
	in mind.

	Use ULA + global addresses.  There is no need to NAT from
	one address to another.  Your internal network connects
	over ULA, you external net connects of a global addresses.
	Even with 1 to 1 NAT in IPv4 you have to use new global
	addresses for people to reach you.

	Note: this works today. link-local + ULA + global.

bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=1b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING>
	inet6 fe80::214:22ff:fed9:fbdc%bge0 prefixlen 64 scopeid 0x1 
	inet6 fd92:7065:b8e:0:214:22ff:fed9:fbdc prefixlen 64 autoconf 
	inet6 2001:470:1f00:820:214:22ff:fed9:fbdc prefixlen 64 autoconf 
	inet 192.168.191.236 netmask 0xffffff00 broadcast 192.168.191.255
	ether 00:14:22:d9:fb:dc
	media: Ethernet autoselect (10baseT/UTP <half-duplex>)
	status: active

% env |grep SSH
SSH_CLIENT=fd92:7065:b8e:0:2e0:29ff:fe19:c02d 4656 22
SSH_CONNECTION=fd92:7065:b8e:0:2e0:29ff:fe19:c02d 4656 fd92:7065:b8e:0:214:22ff:fed9:fbdc 22
% 

	Mark
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Feb 2008 16:33:23 +1300

> While it is surely a factor, I believe the dominant driver for NAT is 

For enterprise networks, certainly, coupled with multihoming.
But absolutely not for SOHO networks, where the dominant driver
is having address space for a LAN.

> just like for v4.  I think you can take that to the bank.

No, you'll have pressure for PI space, which we already see.
As for how to make PI-addressed sites globally reachable without
a scaling problem for the WAN routing system, see the RRG list,
which is really aimed at that challenge IMHO. There's certainly
no need to rush into NAT for that reason. We don't have an
*imminent* scaling problem in IPv6 WAN routing.

> viewed by many as a non-starter.)

Yes, which is why I'm a strong supporter of ULAs. There's no reason
your printers or internal-only servers need globally reachable addresses.

    Brian

---

From: Dan York <[email-masked]>
Date: Mon, 18 Feb 2008 11:51:48 -0500

Brian,

> *imminent* scaling problem in IPv6 WAN routing.

So if I understand you correctly, you believe that:

1. ULAs will give enterprises the addressing autonomy that they seek  
(as RFC 1918 addresses do with IPv4); but that
2. Enterprises will NOT need to use NAT to make those ULAs globally  
reachable (instead using work going on in RRG).

Is that correct?

I will admit that I haven't followed the RRG list at all, but I find  
it hard to wrap my brain around how precisely this would be done  
(outside of servers full of proxies, ALGs, etc.).  Perhaps I've just  
spent far too long in enterprise-land where everything is NAT'd and  
proxied at the firewall with IPv4.  Can you point folks like me to  
some specific work on this that we can read up on?

Agreed.

Regards,
Dan

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 18 Feb 2008 10:09:47 -0800

> From: Rémi Després [mailto:[email-masked]] 
> Sent: Monday, February 18, 2008 5:46 AM
> To: Dan Wing
> Cc: 'Paul Francis'; 'Dan York'; 'Rémi Després'; [email-masked]
> Subject: Re: IPv6 NAT?
> 
> Dan Wing wrote :
> Note that the approach in proposed in an earlier e-mail (and quoted 
> below) provides the "topology and number of hosts obscuring" 
> you discuss.
> It does it without any NAT in the middle.
> 
> ""If a client host takes a new randomly chosen
> SCTP...).""

Sounds like RFC4941.

I do not believe today's application developers are comfortable
with determining if and when their application needs to perform
the functions of RFC4941.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Feb 2008 11:45:08 +1300

Dan,

On 2008-02-19 05:51, Dan York wrote:
> 1. ULAs will give enterprises the addressing autonomy that they seek (as
> RFC 1918 addresses do with IPv4)

Correct. That's available today.

> ; but that

No. When a client system wants to go outside the corporate network, it
will need to use a second address that belongs to a globally routable
prefix. But there's no reason to care about whether that address
has a particularly long lifetime, so it really doesn't matter
whether it's from PI or PA space or whether it will change
next time you reboot the client.

Obviously, external corporate servers (presumably living in
a DMZ) need stable addresses and if they are using PA space,
they can only multihome by using multiple simultaneous
PA prefixes.

This is running code, and it's not the same as IPv4. The long term
scaling issue is how to support PI multihoming. There's no doubt
there will be corporate demand for that.

> 
> Is that correct?
> 
> I will admit that I haven't followed the RRG list at all, but I find it
> hard to wrap my brain around how precisely this would be done (outside
> of servers full of proxies, ALGs, etc.). 

The RRG direction is essentially map-and-encap, but that is a long discussion.

> Perhaps I've just spent far
> too long in enterprise-land where everything is NAT'd and proxied at the
> firewall with IPv4.  Can you point folks like me to some specific work
> on this that we can read up on?

I wouldn't presume... try
http://www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup

   Brian

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 18 Feb 2008 18:16:30 -0800

> From: Rémi Després [mailto:[email-masked]] 
> Sent: Monday, February 18, 2008 11:28 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: IPv6 NAT?
> 
> Dan Wing wrote :
> 
> 
> 		"privacy IID" for each of its outgoing 
> connections: (1) its 
> 		address and
> Basically, it extends use of Privacy IIDs of RFC4941.
> 
> 
> It would not be an application concern.
> If users want this kind of strong privacy,

Typically, users don't know or care; more often it is the network
administrator that cares.

> they activate this 
> "extended privacy option" in their hosts.
> Then the stack below applications applies the "one new 
> address for each outgoing connection" rule.
> Addresses and ports keep their E2E significance for ALL applications.

Thanks for the educating me on where this feature would be implemented.  I
have long assumed that v6 privacy is something the application would need to
be involved with.

Is this functionality already available in Vista and Leopard?

-d

> On the opposite, if NATs MAY be present between the two ends, 
> applications are concerned.
> Some of them may have to work differently depending on 
> whether there is a NAT or not, and depending on which ALG 
> functions it performs.
> That is precisely what can be avoided thanks to IPv6 (and 
> IMHO SHOULD be avoided).
> 
> RD
> 
>

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Feb 2008 00:40:38 -0500

> So, I think it would be good to define IPv6 NAT behavior, and do so
 > NOW before its too late, and define it in a way that it would appeal
 > to the admins that have deployed IPv4 NAT today.

There are at least five things about IPv4 NAT that are not now and never 
were workable:

(1) Changing addresses midstream without the endpoints being aware of 
the change.

(especially in the absence of any other reliable host identifier in the 
IPv4 architecture and a fast, scalable, and reliable id<->address 
mapping facility...an existence proof for which does not yet exist)

(2) The existence of multiple address realms, with some applications 
that communicate across realm boundaries potentially needing to know 
which hosts were in which realms, and which of a host's addresses to use 
from any particular location, and with no way for an application to 
distinguish one realm from another.

(multifaced DNS and its associated problems are ripple effects of this 
general problem, but there are many others)

(3) Overlapping address spaces, with all that this implies, including 
its effects on traceability, increased difficulty in merging networks, 
and difficulty in communicating between networks using the same address 
space.

(4) Address bindings subject to being removed or changed with no notice 
to the endpoints, and no handover.

(5) Arbitrary (from an application's view) blocking of traffic through a 
NAPT for any network sufficiently large or diverse to require different 
policies for different hosts or apps, coupled with the expectation that 
apps operate across those boundaries.

Even assuming some utility for NATs in IPv6 (as a v4-v6 transition tool, 
or for topology hiding) all five of these problems need to be fixed.

--

Offhand, it appears that it might be possible to solve problems 1-5 
above in a NATted IPv6 world.  What would this look like?

- All networks, even those behind NATs, would have globally-unique 
address blocks.

- Every IPv6 host that were permitted to accept traffic from any host 
outside of its enterprise network would have one or more public IPv6 
addresses.

Its ability to use those addresses might be limited by policy, but it 
would still have them, and it would be aware of them.  Such addresses 
could be publicly advertised in DNS, and the public addresses would also 
be usable (whether by hairpin routing or an extension to ND that 
facilitated direct routing) from within the enterprise network. 
Essentially the NAT and the local host would be using NAT as a 
low-overhead tunneling mechanism.

What this would mean (among other things) is that when opening a 
connection to any host that had a public address, it would be reasonable 
to use that address in preference to all other addresses associated with 
that host.

- Address bindings would be able to be explicitly managed by host stacks 
via a standard, authenticated protocol.  Applications would be able to 
access this protocol through a standard API.  "Binding leases" would be 
maintained by the stacks without applications having to be aware of 
them, and applications would be able to request (subject to policy) that 
incoming traffic matching certain criteria (source address, dest 
address, source port, dest port, etc) be permitted to transit the 
nat/firewall.

What would this buy us?

a) A common application framework for communicating between IPv4 and 
IPv6 hosts, and IPv6 and IPv6 hosts, whether or not in the presence of 
NATs...and with it, a way to transition apps from IPv4 to mixed IPv4/v6 
to pure IPv6 with less disruption.

b) Topology hiding for IPv6 networks, and address hiding for client 
hosts on IPv6 networks.  (perhaps better than privacy addresses)

c) The potential for insulation of IPv6 networks from disruption to 
purely-local apps due to renumbering or other changes.  (This would 
require that such apps be configurable to use local addresses in 
preference to global ones, as the default should be the other way around)

d) Something to satisfy people who think they need NAT in IPv6, even if 
they don't understand why they need it and aren't able to evaluate.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Feb 2008 02:02:10 -0500

I hate to rain on the parade, but...

>> 1. ULAs will give enterprises the addressing autonomy that they
>> seek (as RFC 1918 addresses do with IPv4)
> 
>> ; but that 2. Enterprises will NOT need to use NAT to make those
>> ULAs globally reachable (instead using work going on in RRG).
> 
> No. When a client system wants to go outside the corporate network,
> it will need to use a second address that belongs to a globally
> routable prefix.

I still find the notion of "client system", as representative of
anything typical for a computer on a network, to be very dubious.
General purpose computers tend to function as clients for some
protocols, servers for others, and for some protocols they may assume
both roles.  Especially in this day of widespread p2p and otherwise
multiparty apps, it should not be assumed that an ordinary general
purpose computer only functions as a client...not even when 
communicating with external hosts.

I also think it's asking a lot to expect hosts or apps to know when they
need to use a particular address or kind of address...though it might be
reasonable for there to be a small number of special cases for critical,
inherently local apps (if any such apps actually exist).

> But there's no reason to care about whether that address has a
> particularly long lifetime, so it really doesn't matter whether it's
> from PI or PA space or whether it will change next time you reboot the
> client.

The application certainly has reason to care about the lifetime of an 
address that it chooses or that is chosen on its behalf...even if that 
application is only, for the moment, functioning as a client.

Keith

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 19 Feb 2008 01:02:49 -0800

> Sent: Tuesday, February 19, 2008 12:53 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: IPv6 NAT?
> 
> Dan Wing wrote :
> "Users, or network administrators as the case may be," would 
> be better.

Ok, that's fair.

> > have long assumed that v6 privacy is something the 
> > application would need to be involved with.
> > 
> > 
> I ignore whether the "privacy extension of stateless 
> autoconfiguration" of RFC 4941 is supported.
> 
> The "one new address per outgoing connection" rule, which I 
> propose here for the fist time, would IMHO be worth implementing 
> in addition to RFC 4941.
>
> But some more work to specify it in details would be needed 
> before that.
> Some support of the idea would be a prerequisite.

It would be interesting to write it down, and to see what 
would break if the IP stack acquired and provided a fresh
v6 address to every new connection.  Maybe nothing would
break, which would be great.

-d

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 19 Feb 2008 10:21:13 +0100

> break, which would be great.

You really don't want to do that for stuff like the web where you can  
easily end up setting up a dozen new TCP sessions in a second. (Web  
designers use insanely wasteful techniques with multiple external  
javascripts and style sheets per page, often loaded from different  
domains, not to mention the persistent use of spacer images.)  
Duplicate address detection takes too much time to make this useful,  
and the creation of such a large number of addresses makes DAD all the  
more important.

You also don't want to do it for applications that require referrals,  
such as peer-to-peer.

Current address privacy mechanisms change addresses at certain  
intervals, often 24 hours. Last time I checked this was enabled by  
default on Windows (Vista and on XP if IPv6 is enabled) but not on any  
other system, although I believe they all support it.

The reason for this mechanism is not that two sessions can't be  
attributed to the same host, but that when a host moves it can't be  
tracked by its MAC address that would otherwise be in the lower 64  
bits of its IPv6 address when using stateless autoconfig.
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Florian Weimer <[email-masked]>
Date: Tue, 19 Feb 2008 10:23:31 +0100

> Are you saying that there will be IPv6 NAT?

Is a node globally adressable if it never receives any packets you (or
others) send?  From an upper-layer protocol point of view, I'd say it
isn't.

> And that we should design protocols running on top of IPv6 to take NAT  

These protocols need to take into account that if there's a (virtual)
connection between two hosts, it's still not possible to establish
arbitrary other (virtual) connections between them.

> NATs that work with IETF protocols?

I think the NAT question is a bit of a red herring.  I suppose that
anything that is broadly NAT-compatible increases its chances it will
work well on actually deployed networks, be it IPv4, IPv6, or something
else.  However, I don't think we will see as much highly dynamic NAT
(including port translation) on IPv6 as on IPv4.
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Florian Weimer <[email-masked]>
Date: Tue, 19 Feb 2008 10:25:07 +0100

> Obviously #2 is sound

But it's not what will happen on the Internet.  Protocol development
needs to take that into account.
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 19 Feb 2008 11:41:13 +0200

> > autoconfiguration" of RFC 4941 is supported.

It is supported in XP/Vista, and used by default for outgoing connections.
It is supported by Linux, but outgoing connections default to the EUI64 
address. Not sure about OSX.

> break, which would be great.

Overkill.

RFC 5014 already specifies an API to control privacy extensions.

---

From: Rémi Després <[email-masked]>
Date: Tue, 19 Feb 2008 11:47:31 +0100

Iljitsch van Beijnum wrote :

I share the view that, with only the Duplicate Address Discovery
protocol as is, this would be very inefficient.

Some work would be needed to complement the DAD protocol in order to
improve its efficiency for this kind of application.

A number of addresses can at least be acquired in advance, to avoid
delays when they have to be used, but this would clearly not be good
enough.

My feeling is that DAD protocol complements are possible such that  the
extended privacy we talk about would become practicable.

But it seems  unclear at this stage whether, in order to reach the same
privacy and security objective, people will prefer to work on the IPv6
NAT paradygm, or on an Extended Privacy Address paradygm, or on both in
parallel,

My point here is just to discuss an ALTERNATIVE to IPv6 NATs with those
who believe they are unavoidable.

Right.

For these applications, addresses to be reached must be published
somewhere, e.g. in the DNS.

They appear as DESTINATION addresses of newly established connections.

They therefore don't conflict with the"one new address for each outgoing
connection" rule.

(The rule concerns SOURCE addresses, a point which was implicit in what
I wrote, but which may be worth making clearer) .

RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 19 Feb 2008 09:52:40 +0100

> administrator that cares.
Agreed.
"Users, or network administrators as the case may be," would be better.

> Is this functionality already available in Vista and Leopard?
I ignore whether the "privacy extension of stateless autoconfiguration" 
of RFC 4941 is supported.

The "one new address per outgoing connection" rule, which I propose here 
for the fist time, would IMHO be worth implementing in addition to RFC 
4941.
But some more work to specify it in details would be needed before that.
Some support of the idea would be a prerequisite.

RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 18 Feb 2008 14:46:13 +0100

Note that the approach in proposed in an earlier e-mail (and quoted 
below) provides the "topology and number of hosts obscuring" you discuss.
It does it without any NAT in the middle.

RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 18 Feb 2008 15:01:08 +0100

I am not advocating "v6 to v6 NATs", as confirmed by some of my earlier
messages that argue against.

But, if an IPv6-only client has to be able to reach an IPv4-only
server, I keep saying that some NATs will have to deal BOTH with IPv6
(client side) and IPv4 (server side).

As a matter of fact, your recent I-D on MNAT-PT does propose ways of
doing it.

With this clarification, I believe we are in agreement.

RD

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Feb 2008 11:06:29 +1300

Keith,

> communicating with external hosts.

Nevertheless, in the context of enterprise networks that I was addressing,
they are perceived and managed as clients, and the successful p2p
solutions deal with the fact that they have temporary addresses, get
rebooted, and are hidden behind middleboxes. So I'm sticking to my
assertion that long-term address stability just isn't an issue for
desktop and laptop systems. (NAT is an issue, because it breaks sessions.)

> inherently local apps (if any such apps actually exist).

I agree that asking for anything significantly beyond RFC 3484
would be a stretch. But I don't think we need to.

> application is only, for the moment, functioning as a client.

My point is that this is a solved problem in practice. Probably not
solved in the way you or I would like, but solved nevertheless.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Feb 2008 17:19:01 -0500

> solved in the way you or I would like, but solved nevertheless.

Perhaps the meaning of "solved" has changed over the years :)

Several years ago I saw a sign that read:

	Mediocrity is excellence at pursuing the mean.

Keith

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Feb 2008 09:43:53 +1100

> bits of its IPv6 address when using stateless autoconfig.

You also don't want to do it as you would also need massive churn in
the DNS.

Microsoft gets this wrong as they don't register the privacy addresses
in the DNS which in turn causes services to be blocked because there
is no address in the DNS.

Mark

---

From: Rémi Després <[email-masked]>
Date: Wed, 20 Feb 2008 10:08:37 +0100

Mark Andrews wrote :

The proposal is, more precisely, a new fresh v6 address for each
OUTGOING connection.

(A new address per incoming connection wouldn't make sense, right?)

Then, there is no need to concern the DNS with these new addresses:

- Addresses in the DNS would remain stable.

- Hosts would  simultaneously have their advertised address(es),
registered in the DNS, and transient addresses for outgoing connections.

This approach, say "extended privacy with fresh address per
connection",  has been introduced as a potential alternative to v6 to
v6 NATs.

The goal  is to have : (1) privacy and security similar to that of
these NATs; (2)  preservation of E2E significance of addresses and port
numbers.

If there is interest in at least looking at it, more work would clearly
be needed.

In particular, some way to improve the Duplicate Address Discovery
would have to be devised.

IMHO, preserving E2E significance has numerous advantages, worth
extending the scope of studied solutions.

RD

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 20 Feb 2008 12:11:18 +0100

On Wed, Feb 20, 2008 at 10:08:37AM +0100,
 Rémi Després <[email-masked]> wrote 

...
>    Then, there is no need to concern the DNS with these new

Mark Andrews' concern was, I believe, for the many services which
refuse you or, worse, delay you deliberately, when there is no PTR DNS
record for the source IP address (see
draft-ietf-dnsop-reverse-mapping-considerations).
_______________________________________________
Ietf mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Rémi Després <[email-masked]>
Date: Wed, 20 Feb 2008 13:57:18 +0100

Stephane Bortzmeyer wrote :

...

Then, there is no need to concern the DNS with these new
addresses:

Thanks for the comment.

Note that the "fresh part" of addresses we discuss here concerns only
"in-site" information (the IID in the lowest 64 bits).

The first 64 bits of IPv6 addresses are still available to identify
sites from which connections are initiated.

PTR RRs are normally used to get names corresponding to prefixes, not
to addresses, so that there is IMU no reverse DNS problem here.

Not also that v6 to v6 NATs, that this proposal aims at making
unnecessary, tend to be bad in various contexts for remote address
checking applications.

RD

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Feb 2008 00:03:57 +1100

Can't you set your MUA to emit TEXT/PLAIN?  It's just
	plain impolite to send only HTM ~!#!~!#$~ L.

> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
>   <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
> </head>
> <body bgcolor="#ffffff" text="#000000">
> Mark Andrews wrote :
> <blockquote cite="mid:[email-masked]"
>  type="cite">
>   <blockquote type="cite">
>     <pre wrap="">On 19 feb 2008, at 10:02, Dan Wing wrote:
>     </pre>
>     <blockquote type="cite">
>       <pre wrap="">It would be interesting to write it down, and to see what
>       </pre>
>     </blockquote>
>   </blockquote>
>   <pre wrap=""><!---->
>   </pre>
> </blockquote>
> OUTGOING connection.<br>

	There are plenty of services that want working reverse
	lookups before they will let you in.  So yes, OUTGOING needs
	to be registered in the DNS as much as INCOMING.  In addition
	that registration has to propogate to all the authoritative
	servers for the relevent zones.
	
> (A new address per incoming connection wouldn't make sense, right?)<br>
> Then, there is no need to concern the DNS with these new addresses:<br>
> - Addresses in the DNS would remain stable.<br>
> - Hosts would&nbsp; simultaneously have their advertised address(es),
> registered in the DNS, and transient addresses for outgoing connections.<br>
> <br>
> connection",&nbsp; has been introduced as a potential alternative to v6 to
> v6 NATs.<br>
> The goal&nbsp; is to have : (1) privacy and security similar to that of
> these NATs; (2)&nbsp; preservation of E2E significance of addresses and port
> numbers.<br>
> <br>
> be needed.<br>
> would have to be devised.<br>
> extending the scope of studied solutions.<br>
> <br>
> RD<br>
> <br>
> </body>
> </html>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 20 Feb 2008 14:13:21 +0100

[Mark Andrews is right, it is very difficult to separate your message
from the parts you quote, my mail reader does not have a HTML
parser !]

On Wed, Feb 20, 2008 at 01:57:18PM +0100,
 Rémi Després <[email-masked]> wrote 
 a message of 44 lines which said:

>    The first 64 bits of IPv6 addresses are still available to
>    identify sites from which connections are initiated.

I was not speaking about you *can* do but about what people *do*
today. A lot of people use the existence (or not) of a PTR record to
grant you access or not. You may tell them "PTR is useless, use the
first 64 bits of the address instead", they won't listen.

>    PTR RRs are normally used to get names corresponding to prefixes,
>    not to addresses, so that there is IMU no reverse DNS problem
>    here.

AFAIK, there is no DNS way to resolve prefixes into names (RFC 1101,
may be? Can we apply it to IPv6 addresses?). A PTR is for a complete
adress, not for a prefix.

---

From: Rémi Després <[email-masked]>
Date: Wed, 20 Feb 2008 15:42:43 +0100

Stephane Bortzmeyer wrote :
>  from the parts you quote, my mail reader does not have a HTML parser
>  !]
Thanks.
I will try to be more careful.

> On Wed, Feb 20, 2008 at 01:57:18PM +0100, Rémi Després 
> <[email-masked]> wrote a message of 44 lines which said:
> 
I didn't tell anybody that PTRs were useless (and don't think it
either!) :-).

>> not to addresses, so that there is IMU no reverse DNS problem here.
>> 
>> 
> 
I have to recognize that my knowledge of the DNS needs improvements.
Sorry for that.
Thanks for the rectification.
As I now se it, I wrongly interpreted PTR RRs used for zone delegation
as RRs that could also be used to identify sources.

Then the point is different.
An advantage of NATs, for remote host identification, is that a host
name given to a NAT device serves as substitute name to all real hosts
behind this NAT.

A similar result could be achieved if resolvers, when they have to get a
name for an IPv6 address having a privacy ID, instead of having no
chance to get any name, would replace this ID by an agreed standard
value for which there is a PTR RR.

RD

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 20 Feb 2008 15:58:27 +0100

On Wed, Feb 20, 2008 at 03:42:43PM +0100,
 Rémi Després <[email-masked]> wrote 
 a message of 49 lines which said:

> A similar result could be achieved if resolvers, when they have to
> get a name for an IPv6 address having a privacy ID, instead of
> having no chance to get any name, would replace this ID by an agreed
> standard value for which there is a PTR RR.

It seems a good idea.

RFC 1101 is probably the right basis for such a feature (which does
not exist today). So, the roadmap is:

* write a RFC 1101bis, mostly to introduce IPv6 support
* convince the resolver's authors to use it (it requires code on their
  side)

---

From: Rémi Després <[email-masked]>
Date: Wed, 20 Feb 2008 17:00:43 +0100

Stephane Bortzmeyer wrote :
> On Wed, Feb 20, 2008 at 03:42:43PM +0100, Rémi Després
> <[email-masked]> wrote a message of 49 lines which said:
> 
>> having no chance to get any name, would replace this ID by an
>> agreed standard value for which there is a PTR RR.
> 
> It seems a good idea.
Thanks.

> * write a RFC 1101bis, mostly to introduce IPv6 support * convince
> the resolver's authors to use it (it requires code on their side)
Assuming that a RFC would describe the mechanism (1101bis or another) 
and that such a standard value would be found, I believe resolver 
developpers shouldn't be too reluctant to add this in a next release 
(full upward compatibility).

NB: unless there are objections I don't know, the value could simply be 
0:0:0:0, to mean "unknown IID".

Could we discuss all this in Philadelphia?

RD

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 20 Feb 2008 22:51:00 +0100

> is no address in the DNS.
perhaps the advent of IPv6 will result in people finally (*finally*)
giving up on this sorry excuse for a security blanket? (calling it a
"mechanism" is too kind)

Or perhaps it'll just make people register wildcard records at the /64
level in ip6.arpa :-(

             [email-masked] (MY, what an useful
reverse map!)

IETF mailing list
[email-masked]

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 21 Feb 2008 12:37:02 +0100

>              [email-masked] (MY, what an useful

Like a lot of things, "it depends".

For SMTP/SSH and for management-alike protocols requiring proper
reverse -> forward -> reverse mapping is IMHO a good thing.

Clients & servers using these protocols  should be on stable & trackable 
addresses. (of course you an set a low TTL etc, that is why one should 
always log the name + IP, the more information the better). With 
management I mean for instance reverses on router IP addresses, as it 
makes traceroute so much more informative, also reverses on servers etc.

For SSH you will most likely have firewall rules in place anyway. SMTP 
should similarly only be allowed to clients that are in your client 
list. One doesn't have to require r->f->r if the client is in your 
client-list of course. Your server, which talks to other SMTP servers 
outside of your control, should be on a stable IP and have functioning 
r->f->r. For SMTP the current track of mind is: no reverse, no 
communication. Which stops most of the spam already, as that client is 
clearly not configured correctly to do inter-domain SMTP.

For that matter anything that is 'stable' should (note should) IMHO have 
a proper r->f->r.

For any other protocol _requiring_ reverse is silly IMHO.
You don't need it for HTTP, you don't need it for BitTorrent etc.
Having reverse in those cases is nice, as it might give extra 
information (eg the remote is most likely dsl as it contains 'dsl' in 
the reverse), but it is always a guess and might quite well be faked.

The biggest issue with the use of reverses tends to be with applications 
which only lookup a reverse, but don't check if the r->f->r link is 
complete.

Greets,
  Jeroen

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 21 Feb 2008 12:55:19 +0100

Jeroen Massar wrote:
> Clients & servers using these protocols  should be on stable & 
> trackable addresses. (of course you an set a low TTL etc, that is why 
> one should always log the name + IP, the more information the better). 
> With management I mean for instance reverses on router IP addresses, 
> as it makes traceroute so much more informative, also reverses on 
> servers etc.
>
> For that matter anything that is 'stable' should (note should) IMHO 
> have a proper r->f->r.
>
> The biggest issue with the use of reverses tends to be with 
> applications which only lookup a reverse, but don't check if the 
> r->f->r link is complete. 
The biggest issue with reverse mapping for clients (any protocol) is 
that people try to make their applications treat it as anything but 
"here is some information you might find interesting".

I think draft-ietf-dnsop-reverse-mapping-considerations-05.txt has it right:

4.3 Application considerations

   Applications should not rely on reverse mapping for proper operation,
   although functions that depend on reverse mapping will obviously not
   work in its absence.  Operators and users are reminded that the use
   of the reverse tree, sometimes in conjunction with a lookup of the
   name resulting from the PTR record, provides no real security, can
   lead to erroneous results and generally just increases load on DNS
   servers.

FYI, I ssh out from the address I used as an example above every day. 
Thinking that SSH clients should be required to be on round-trippable 
mapped addresses is just silly.

                 Harald

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 21 Feb 2008 14:45:33 +0100

On 21 feb 2008, at 14:31, Rémi Després wrote:

> - These addresses would, for example, have  FF00::/8 at the  
> beginning of their IID  (no currently specified IPv6 IID begins that  
> way; randomness on 58 bits is good enough).

You're right, there is currently no way other than a rather non- 
obvious use of manual address configuration or DHCPv6 address pool  
configuration to arrive at an interface identifier where the U/L bit  
is "global" and the group bit is set, i.e., with bits 6 and 7 of the  
IID set to 1. This means that there is an untapped range of 62 bits  
worth of IIDs that we can still give a new purpose where the address  
type can be relatively unambiguously determined from the IID. It would  
be a shame to squander that resource without thinking about other uses  
first. (Although using only one of the 64 possible ranges of 56 bits  
is probably reasonalbe.)

But shouldn't we be having this discussion in 6man?
_______________________________________________
IETF mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 21 Feb 2008 14:47:03 +0100

Rémi Després wrote:
> Harald Alvestrand a écrit :
>> Mark Andrews skrev:
>>   
> One approach to achieve it could be ias follows:
> -  An IPv6 link  where some privacy source addresses may be used would 
> have in the DNS a record for a "generic privacy address".
> -  This address would  be the /64 of the  link followed by an agreed 
> "joker IID" (0:0:0:0 or some other to be agreed on, e.g. FFFF:0:0:0).
> -  Resolvers, if they recognize a privacy remote address, would query 
> the reverse DNS with this "generic privacy address"  of the remote link.
> -  They could also do this type of queries after failures of full 
> address queries.
>
> Problem:
> Privacy addresses, as specified today, cannot be distinguished with 
> 100% certainety from addresses obtained with stateful DHCPv6.
> A proposal would be an addition to the privacy extension spec (rfc 4941).
> - A variant of privacy addresses would be defined for "dsitinguishable 
> privacy addresses".
> - These addresses would, for example, have  FF00::/8 at the beginning 
> of their IID  (no currently specified IPv6 IID begins that way; 
> randomness on 58 bits is good enough).
> - Then resolvers could recognize such privacy addresses for sure, and 
> could query the reverse DNS with the  generic privacy address only 
> when this is appropriate.
>
> IMHO, this is a feasible step to reconcile: (1) privacy requirements 
> of individuals; (2)  desire to know which site is at the other end 
> where and when such a desire exists.
My desire to have privacy is, in itself, something I may want to keep 
private.

If what you want to know is indeed "which site is at the other end", 
wildcards at the /64 level will achieve that with no changes to existing 
code.

                 Harald

---

From: Rémi Després <[email-masked]>
Date: Thu, 21 Feb 2008 14:51:07 +0100

This is a retransmission with a source address accepted on this
discussion list.

Apologies to those who received it already.

If you respond, please use preferably this copy.

RD

Harald Alvestrand wrote:

Mark Andrews skrev:

Problem:

A proposal would be an addition to the privacy extension spec (rfc
4941).

- Then resolvers could recognize such privacy addresses for sure, and
could query the reverse DNS with the  generic privacy address only when
this is appropriate.

IMHO, this is a feasible step to reconcile: (1) privacy requirements of
individuals; (2)  desire to know which site is at the other end where
and when such a desire exists.

RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 21 Feb 2008 15:24:07 +0100

>> randomness on 58 bits is good enough).
(Sorry for the typo. Should be 56.)
> You're right, there is currently no way other than a rather non-obvious 
> use of manual address configuration or DHCPv6 address pool configuration 
> to arrive at an interface identifier where the U/L bit is "global" and 
> the group bit is set, i.e., with bits 6 and 7 of the IID set to 1. This 
> means that there is an untapped range of 62 bits worth of IIDs that we 
> can still give a new purpose where the address type can be relatively 
> unambiguously determined from the IID. It would be a shame to squander 
> that resource without thinking about other uses first. (Although using 
> only one of the 64 possible ranges of 56 bits is probably reasonalbe.)
> 
Yes, I think so.

---

From: Rémi Després <[email-masked]>
Date: Thu, 21 Feb 2008 15:32:01 +0100

> My desire to have privacy is, in itself, something I may want to keep 
I am not sure I see the practical consequences.
If my source address says "I am someone but you will not know who I am", 
isn't this sufficient?

> wildcards at the /64 level will achieve that with no changes to existing 

I am not familiar enough with wildcard operation in the DNS.
If it provides for queries that concern only site prefixes, then you are 
right: no need for an agreed "wildcard IID".
The result is the same with existing mechanisms, which is clearly better.

RD

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 21 Feb 2008 16:34:04 +0100

Rémi Després wrote:
> If my source address says "I am someone but you will not know who I 
> am", isn't this sufficient?

You're not thinking this through.

Think of the case where there are 1000 users on a LAN, and one of them 
desires to use the address privacy option for all the normal reasons.

Then think about the policeman / bad guy / secret agent / mafioso with a 
trace of all traffic from that LAN - he can immediately say that the 999 
were using non-privacy-enhanced addresses, and the resulting trace will 
show him immediately what the 1000th was up to, no matter how many times 
he changed his address.
>> wildcards at the /64 level will achieve that with no changes to 
>> existing code.
>
> If it provides for queries that concern only site prefixes, then you 
> are right: no need for an agreed "wildcard IID".
Read RFC 1034 - or perhaps better, RFC 4592. They've been around for a 
while (although their behaviour still surprises many).

                        Harald

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 21 Feb 2008 17:07:58 +0100

> show him immediately what the 1000th was up to, no matter how many  

I'm assuming you mean "a trace of the activities of addresses from  
that LAN as seen from elsewhere", because if they can sniff the LAN  
they can also see the link addresses.

But what the good/bad guy sees is 1099 addresses, 999 of which are  
used for somewhat long periods, and 100 of which are used for somewhat  
short periods. They don't know how many users there were on the LAN,  
although they can probably guess to within 10% or so based on the  
amount of traffic. They also don't have any way to know which user was  
using which privacy address at any given time unless they had a much  
more intimite view of the LAN in question.
_______________________________________________
IETF mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Rémi Després <[email-masked]>
Date: Thu, 21 Feb 2008 17:32:23 +0100

> show him immediately what the 1000th was up to, no matter how many times 

Right if the user keeps the same address for a series of outgoing 
connections.
However things are different in the context in which I proposed, in 
earlier mails of the same thread, that the resolver would query the DNS 
for site prefixes.

The concern was client hosts for which one desires both: (1) a privacy 
similar to that offered by NATs; (2) undisturbed E2E significance of 
addresses and ports.

For this, the idea at hand is that these clients would use a fresh 
privacy address for each outgoing connection (with some more 
specification work left to avoid unreasonable Duplicate Address Detection).

If this is done, the poor mafioso will believe that consecutive 
connections of a single host are connections initiated by various hosts 
(or at least will be unable to decide which connections come from the 
same host) :-).

> while (although their behaviour still surprises many).
Thanks.
I will have a look.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 21 Feb 2008 17:58:12 +0100

> more intimite view of the LAN in question.
Unless you implement an identifiable format for privacy enhanced 
addresses; in that case they can 100% accurately say that 100 addresses 
were "used by someone with something to hide".

That was the idea I was trying to point out the bad sides of.