Subject: [BEHAVE] FW: New Version Notification for draft-bellis-behave-natpresent-00.txt

From: Ray Bellis <[email-masked]>
Date: Mon, 24 Oct 2011 08:58:24 +0000

Forwarded for the group's information:

The primary intent is for Layer 7 applications to be able to receive explicit in-band notification of modifications at L3/L4.

--8<--8<--
Subject: New Version Notification for draft-bellis-behave-natpresent-00.txt

A new version of I-D, draft-bellis-behave-natpresent-00.txt has been successfully submitted by Ray Bellis and posted to the IETF repository.

Filename:        draft-bellis-behave-natpresent
Revision:        00
Title:           Signalling the Presence of NAT
Creation date:   2011-10-23
WG ID:           Individual Submission
Number of pages: 7

Abstract:
  End-to-end applications have difficulty distinguishing between
  packets that have been passed through a Network Address Translator
  (NAT) and packets that have been passed along a clear end-to-end
  path.  We propose mechanisms for IPv4 and IPv6 whereby NAT devices
  explicitly signal their operation as a means of allowing applications
  to distinguish the presence of otherwise undetected NATs in the end-
  to-end path.

--8<--8<--

Ray

---

From: Simon Perreault <[email-masked]>
Date: Mon, 24 Oct 2011 08:27:01 -0400

Before I comment on this draft, I would like the authors to confirm that
this is not a joke. I'm detecting high levels of humour and sarcasm, and
trace amounts of craziness.

:)

Simon

On 2011-10-24 04:58, Ray Bellis wrote:
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Ray Bellis <[email-masked]>
Date: Mon, 24 Oct 2011 12:35:49 +0000

> trace amounts of craziness.

No, it is _not_ a joke.

It _may_ well be crazy, but I figured we wouldn't know that until other people have had a chance to think about it ;-)

Ray

---

From: Simon Perreault <[email-masked]>
Date: Mon, 24 Oct 2011 08:49:59 -0400

>> trace amounts of craziness.

Thanks. Here are some initial, high-level comments:

I don't think this draft solves an existing problem. What applications
need to know is *not* if there is a NAT in the path. They don't care.
They especially don't care in cases where there are two NATs in the path
where one reverses the other's mapping (yes it happens).

What applications need to know is "what public IP address+port am I
mapped to when I talk to XYZ". This is the piece of information that is
needed to establish a direct peer-to-peer connection via a rendez-vous
server. And the way to do that is the infamous STUN/TURN/ICE. It's
complex because it needs to be.

I think I'm looking for an answer to the following question:
How should apps modify their behaviour when they see the evil bit?

The draft says:

4. Application Processing

   Applications that receive a packet with a non-zero NAT Present option
   MUST assume that the IP header's source and destination address, the
   transport level source and destination ports and even the IP version
   value may have been altered by a NAT in the end-to-end path.

What should the assume_nat() function I'm about to add to my app contain?

Simon

---

From: Ray Bellis <[email-masked]>
Date: Mon, 24 Oct 2011 13:14:46 +0000

> How should apps modify their behaviour when they see the evil bit?

Who said "evil bit" ?! ;-)

> What should the assume_nat() function I'm about to add to my app contain?

Whatever it wants, of course!

As it happens, the original idea came to me as a way of allowing applications to "prefer" end-to-end clear paths over paths that go through a CGN, i.e. an extra piece of information for "Happy Eyeballs" algorithms.

Over on v6ops certain operators were bemoaning that certain OS software folks won't use V6 in preference to a V4 CGNed path if all else were equal, where "equal" is AFAIK only assessed based on RTT.

The operators would rather have more V6 traffic than have everyone fill up their CGNs.  The alternative would be for them to introduce artificial delays in their V4 CGN paths to ensure that V6 wins.  This was actually proposed on list! 

This then, is a way to provide a second-order measure of "equality".

There's plenty of other stuff too which Geoff can probably explain better than I can, but I expect he's asleep just now.

Ray

---

From: Simon Perreault <[email-masked]>
Date: Mon, 24 Oct 2011 09:57:24 -0400

On 2011-10-24 09:14, Ray Bellis wrote:
> As it happens, the original idea came to me as a way of allowing
> applications to "prefer" end-to-end clear paths over paths that go
> through a CGN, i.e. an extra piece of information for "Happy
> Eyeballs" algorithms.

Got it. That makes sense. But we already have STUN for that, don't we?
And STUN doesn't require cooperation from the NAT.

Thanks,
Simon

---

From: Ray Bellis <[email-masked]>
Date: Mon, 24 Oct 2011 14:26:43 +0000

> And STUN doesn't require cooperation from the NAT.

The intention was for something lighter weight (and in-band).

Ray

---

From: Christian Huitema <[email-masked]>
Date: Mon, 24 Oct 2011 18:18:26 +0000

> The intention was for something lighter weight (and in-band).

Wouldn't it be nice to have a version of trace route that somehow returned the list of NAT on the path, as well as the succession of translations?

-- Christian Huitema

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 24 Oct 2011 11:35:38 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Christian Huitema
> Sent: Monday, October 24, 2011 11:18 AM
> To: Ray Bellis; Simon Perreault
> Cc: [email-masked]
> Subject: Re: [BEHAVE] New Version Notification for draft-bellis-behave-
> natpresent-00.txt
> 
> Wouldn't it be nice to have a version of trace route that somehow
> returned the list of NAT on the path, as well as the succession of
> translations?

Yes.  I am planning to introduce that idea to PCP proxying soon after
we wrap up pcp-base.

-d

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Oct 2011 22:11:51 +0300

Funny enough we did all this in NSIS ;-)

---

From: Christian Huitema <[email-masked]>
Date: Mon, 24 Oct 2011 19:17:21 +0000

I am aware of NSIS. But the premise of NSIS is that software gets implemented in the translators, and that has proven quite hard. A "trace route" approach would work even if a minority of the routers on the path supported it.

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Monday, October 24, 2011 12:12 PM
To: Dan Wing
Cc: Hannes Tschofenig; Christian Huitema; 'Ray Bellis'; 'Simon Perreault'; [email-masked]
Subject: Re: [BEHAVE] New Version Notification for draft-bellis-behave-natpresent-00.txt

On Oct 24, 2011, at 9:35 PM, Dan Wing wrote:

>> Subject: Re: [BEHAVE] New Version Notification for 
>> draft-bellis-behave- natpresent-00.txt
>>