Subject: [Ietf-behave] Where we are with draft-audet-nat-behave

From: "Francois Audet" <[email-masked]>
Date: Tue, 31 Aug 2004 16:08:03 -0700 (PDT)

I'd like to summarize where I think we are with draft-audet-nat-behave.

I would like to be able to issue a new release of the document soon,
so I will put on the table the things that were agreed-to in San Diego,
and what my take is on the mailing list discussions.

I'm writing this from the point of view of the changes to expect between
version -00 and -01. I would like to advance the document to a new
version, with the things that have a good concensus on, and highlight
where there is no concensus yet.

I'd like to get a view of "yes/no" on the following bullet items. 

1 - From San Diego, it was agreed to explicitely limit the scope to 
    NATs, and exclude Firewalls. The document will make that clear,
    and will only cover the intrinsic filtering aspects of NATs. 

2 - I believe we have a broad concensus that this first document will 
    ONLY cover UDP Unicast. TCP, Multicast, ICMP, etc. are to be 
    covered in later draft(s). 

3 - I'm not sure if we should include fragmentation or not (any views?).

4 - We will still try to think a bit about UDP multicast, and try to
    ensure our UDP unicast requirements will not make supporting UDP
    multicast later on problematic. (see 7)
    
5 - From San Diego: state that scope stops at UDP layer (i.e., RTP, or
    ALGs are out-of-scope). No looking at embedded addresses for example.

6 - From San Diego: State that one of the goals is to lessen the 
    dependence on Media Relays.

7 - On the binding refresh issue, as it stands now, I am inclined to go
    with Dan Wing's suggestion which essentialy says that "Outbound 
    traffic MUST refresh the binding" and "Inbound traffic MAY also
    refresh the binding". (I.e., I've been convinced by the arguments
    against the "outbound-only" position I was advocating earlier). And
    we will be silent on multicast.

Can you guys tell me what you think? 

Thanks.

----
François AUDET, Nortel Networks
Tel: +1 408 495 3756

---

From: Geoff Huston <[email-masked]>
Date: Tue, 31 Aug 2004 16:43:48 -0700 (PDT)

I'd like to get a view of "yes/no" on the following bullet items.
thanks  - my responses are listed against your items....

yes

yes

3 - I'm not sure if we should include fragmentation or not (any views?).
Fragmentation should be included in my view - it is part of the variability
of NAT implementations today and some clear statement of behavioural
variability that are seen today would be helpful imho.
4 - We will still try to think a bit about UDP multicast, and try to
    ensure our UDP unicast requirements will not make supporting UDP
    multicast later on problematic. (see 7)
yes - although I'm cautious  about this, as it may reopen the previous
question!
5 - From San Diego: state that scope stops at UDP layer (i.e., RTP, or
    ALGs are out-of-scope). No looking at embedded addresses for example.
yes

6 - From San Diego: State that one of the goals is to lessen the
    dependence on Media Relays.
yes - assuming that the distinction here is between media relays and 
application agents.

yes

regards,

   Geoff

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Aug 2004 17:22:10 -0700 (PDT)

...
> 2 - I believe we have a broad concensus that this first 
> document will ONLY cover UDP Unicast. TCP, Multicast, ICMP, 
> etc. are to be covered in later draft(s). 

I believe we need to cover UDP and ICMP as the received ICMP 
message apply to those UDP packets that were sent by the NAT.

If a NAT 'eats' an ICMP message, or uses a certain ICMP message 
to close its UDP binding, it has significant operational 
effects on an application -- especially if the application 
didn't receive the ICMP message (due to congestion on the
home Ethernet network or home wireless network, for example).

Similarly, I believe the TCP document needs to describe ICMP
as those ICMP messages apply to the TCP packets that were 
sent by the NAT.

> 3 - I'm not sure if we should include fragmentation or 

I agree with Geoff - the handling of fragmentation is variable
and needs to be discussed.  This doesn't mean we'll necessarily
require reassembly in a NAT to be BEHAVE-compliant, but we need
to describe how fragmentation in should be handled.

We need to discuss both incoming fragmentation (packet arrives
in fragments) and outgoing fragmentation (I believe there are
two cases, (a) host set DF=1, and NAT discovers the access link 
is too small to handle it [PPPoE], and (b) NAT sends packet and
receives ICMP 'fragmentation needed DF set' packet, what should
it do.

To do this, we'll need to mention ICMP ('fragmentation needed 
DF set').

...
> Can you guys tell me what you think? 

The others items all sound fine to me.

-d

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 31 Aug 2004 19:32:55 -0700 (PDT)

My take inline:

Francois Audet wrote:

Yes.

2 - I believe we have a broad concensus that this first document will
    ONLY cover UDP Unicast. TCP, Multicast, ICMP, etc. are to be
    covered in later draft(s).
I think separate drafts are fine, but there are UDP/ICMP interactions as 
has already been commented. As such, the ICMP and UDP documents may need 
to be done jointly.

Definitely yes!

Yes.

Yes.

Yes.

OK.

-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@xxxxxxxxxxxxxxx                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Melinda Shore <[email-masked]>
Date: Wed, 1 Sep 2004 07:46:54 -0700 (PDT)

On Tuesday, August 31, 2004, at 07:05 PM, Francois Audet wrote:
1 - From San Diego, it was agreed to explicitely limit the scope to
    NATs, and exclude Firewalls. The document will make that clear,
    and will only cover the intrinsic filtering aspects of NATs.
Absolutely.

Yes

3 - I'm not sure if we should include fragmentation or not (any 
views?).
Definitely, if the goal is to describe what NAT designers need to do
to make their devices more well-behaved.
4 - We will still try to think a bit about UDP multicast, and try to
    ensure our UDP unicast requirements will not make supporting UDP
    multicast later on problematic. (see 7)
Okay.

5 - From San Diego: state that scope stops at UDP layer (i.e., RTP, or
    ALGs are out-of-scope). No looking at embedded addresses for 
example.
I'd state it a little differently - that we're dealing only with 
transport
layer and below issues.

6 - From San Diego: State that one of the goals is to lessen the
    dependence on Media Relays.
Meh.  I'd try to keep this from being too voice-ish.  Media relays
are an instance of a broader class of problem, which is the (perceived)
need to introduce new devices and functions into networks in order to
work around problems introduced by NAT.  Other applications, notably
online gaming and peer-to-peer applications, have the same problem.
I'd prefer to see this broadened.
7 - On the binding refresh issue, as it stands now, I am inclined to go
    with Dan Wing's suggestion which essentialy says that "Outbound
    traffic MUST refresh the binding" and "Inbound traffic MAY also
    refresh the binding". (I.e., I've been convinced by the arguments
    against the "outbound-only" position I was advocating earlier). And
    we will be silent on multicast.
Yes.

Melinda

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 14 Sep 2004 10:08:34 -0700 (PDT)

With my contributor hat on ...

yes

>     covered in later draft(s).
TCP is out, multicast out other than the wording on separate thread for
inbound/outbound updates. I think ICMP needs to be dealt with at least a
little bit. 

> 3 - I'm not sure if we should include fragmentation or not (any views?).
Think we should mention it. Not sure what to say. I don't think UDP
fragmentation will be covered in any other document.

yes

yes

>     dependence on Media Relays.
sure but this is just introduction stuff and one of several motivations

yes