Subject: RE: [Ietf-behave] NAT behave draft

From: "Francois Audet" <[email-masked]>
Date: Thu, 19 Aug 2004 16:15:20 -0700 (PDT)

No, I 
think you understand properly.
<FONT face=Arial color=#800000 
size=2> 
It 
would mean that if you are good enough to support multicast, you need to support 
the second document.
<FONT face=Arial color=#800000 
size=2> 
I 
guess one question I have is, does Multicast work today with home 
NATs?
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px solid; MARGIN-RIGHT: 0px">
  
  <FONT 
  face=Tahoma size=2>-----Original Message-----From: Spencer Dawkins 
  [mailto:spencer@xxxxxxxxxxxxx] Sent: Thursday, August 19, 2004 
  16:11To: ietf-behave@xxxxxxxxxxxxxxxxxxxSubject: Re: 
  [Ietf-behave] NAT behave draft
  I may have misunderstood the thread, but I thought the 
  request was that BEHAVE NATs are multicast-aware enough that they don't break 
  multicast (by dropping all multicast packets, for instance)... were we talking 
  about something else?
   
  Spencer
  <BLOCKQUOTE 
  style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    ----- Original Message ----- 
    <DIV 
    style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black">From: 
    <A title=audet@xxxxxxxxxxxxxxxxxx 
    href="mailto:audet@xxxxxxxxxxxxxxxxxx">Francois Audet 
    To: <A title=jdrosen@xxxxxxxxxxxxxxx 
    href="mailto:jdrosen@xxxxxxxxxxxxxxx">'Jonathan Rosenberg' ; <A 
    title=laforge@xxxxxxxxxxxxx href="mailto:laforge@xxxxxxxxxxxxx">'Harald 
    Welte' 
    Cc: <A 
    title=ietf-behave@xxxxxxxxxxxxxxxxxxx 
    href="mailto:'ietf-behave@xxxxxxxxxxxxxxxxxxx'">'ietf-behave@xxxxxxxxxxxxxxxxxxx' 
    
    Sent: Thursday, August 19, 2004 4:59 
    PM
    Subject: RE: [Ietf-behave] NAT behave 
    draft
    
    > I don't see the problem here, actually. Why can't we 
    specify > different > 
    keepalive rules for multicast and unicast? The two are readily 
    > differentiated in the NAT by the IP address. 
    For multicast, there > basically is a "keepalive" 
    from the inside to the out - IGMP. If the > user 
    decides to leave the group, packets won't be forwarded, <FONT 
    size=2>> and there > is no problem. 

    That's kind of my thinking too. 
    Isn't there a way the NAT can distinguish between multicast 
    traffic and uniscast traffic are apply different 
    rules? 

    _______________________________________________Ietf-behave 
    mailing 
    listIetf-behave@xxxxxxxxxxxxxxxxxxxhttps://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 22 Aug 2004 23:01:05 -0700 (PDT)

Given the advice we got at the meeting, I would be happiest to propose we do the "UDP Unicast" stuff in one of our first documents then do the "Multicast" stuff in a later document. 

That said, I think that considering how our future work might break the UDP Unicast work is completely appropriate. We probably need some clue of how we might solve the multicast timeouts issues when we get to them and if that would require changers to the UDP document we need to contemplate that now.

I can see several discussion paths we might pursue:
treat multicast traffic differently
do outbound keep alives in multicast applications
update timeouts on inbound packets for unicast UDP

Thoughts on pros/cons of these?

Cullen

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 23 Aug 2004 04:29:28 -0700 (PDT)

I'm not disagreeing on the "work on unicast UDP first" 
strategy, but I do have a question.
 
If I understand the justification for BEHAVE, the idea is to 
have BCP-strength specifications that vendors and operators will use, and then 
(they will most likely) claim "BCP 110" (more likely "RFC 4112", but that's a 
NEWTRK problem) compliance.
 
If we don't work on multicast at this time, I think we're 
saying "we don't care if people break multicast now - if their NATs drop all 
multicast traffic, they can stilll say they comply with IETF BCPs for NAT, 
and that's OK".
 
Is that what we're saying?
 
Spencer
<BLOCKQUOTE 
  ----- Original Message ----- 
  <DIV 
  Cullen Jennings 
  
  To: <A title=audet@xxxxxxxxxxxxxxxxxx 
  href="mailto:audet@xxxxxxxxxxxxxxxxxx">Francois Audet ; <A 
  title=dwing@xxxxxxxxx href="mailto:dwing@xxxxxxxxx">Dan Wing ; <A 
  title=ietf-behave@xxxxxxxxxxxxxxxxxxx 
  href="mailto:ietf-behave@xxxxxxxxxxxxxxxxxxx">Behave ; <A 
  title=jiri@xxxxxxxxx href="mailto:jiri@xxxxxxxxx">Jiri Kuthan 
  Sent: Sunday, August 22, 2004 8:49 
  PM
  Subject: [Ietf-behave] UPD and Multicast 
  scope
  <SPAN 
  style="FONT-SIZE: 14px">Given the advice we got at the meeting, I would be 
  happiest to propose we do the "UDP Unicast" stuff in one of our first 
  documents then do the "Multicast" stuff in a later document. That 
  said, I think that considering how our future work might break the UDP Unicast 
  work is completely appropriate. We probably need some clue of how we might 
  solve the multicast timeouts issues when we get to them and if that would 
  require changers to the UDP document we need to contemplate that now.I 
  can see several discussion paths we might pursue:
  
    <SPAN 
    style="FONT-SIZE: 14px">treat multicast traffic differently 
    do 
    outbound keep alives in multicast applications 
    <SPAN 
    style="FONT-SIZE: 14px">update timeouts on inbound packets for unicast 
    UDP<SPAN 
  style="FONT-SIZE: 14px">Thoughts on pros/cons of 
  these?Cullen

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 23 Aug 2004 09:44:20 -0700 (PDT)

I like (1), because multicast is already handled differently by the NATs --
to do multicast they have to see an IGMP from the Ethernet-attached
computer, propagate the IGMP towards the service provider, and set up a NAT
binding.

What is critical in the base document is that the base BEHAVE document
allows incoming-only multicast packets to keep the NAT binding open.  I
suggest the following straw-man wording in BEHAVE:

    For unicast traffic, a binding MUST remain open if a UDP packet is sent
    from an inside address to an outside address. Additionally, unicast UDP
    bindings MAY be kept open if a UDP packet is received from the
    outside to the inside. Requirements for timing out these bindings
    are in section X.Y.Z.

Section X.Y.Z can talk about timeouts being a MUST.  In a glossary we need
to define 'unicast traffic' as an IP packet with an IP source unicast
address and IP destination unicast address.

I feel we should be silent on multicast (and probably also IPsec Security
Parameters Index (SPI)), so that they can be fully described in their own
separate document.

-d

-----Original Message-----
From: Cullen Jennings [mailto:fluffy@xxxxxxxxx]
Sent: Sunday, August 22, 2004 6:50 PM
To: Francois Audet; Dan Wing; Behave; Jiri Kuthan
Subject: UPD and Multicast scope

Given the advice we got at the meeting, I would be happiest to propose we do
the "UDP Unicast" stuff in one of our first documents then do the
"Multicast" stuff in a later document.

That said, I think that considering how our future work might break the UDP
Unicast work is completely appropriate. We probably need some clue of how we
might solve the multicast timeouts issues when we get to them and if that
would require changers to the UDP document we need to contemplate that now.

Cullen

---

From: Geoff Huston <[email-masked]>
Date: Mon, 23 Aug 2004 15:56:04 -0700 (PDT)

Spencer, you seem to be taking that view that the period between these two 
documents would be an extended one - perhaps measured in geological eons ( 
:-) ). While that may indeed be a useful metric for measuring the progress 
of IETF documents these days, I'm not sure that it has to be this way, and 
in the case of writing down NAT behaviours and what is a reasonable set of 
such behaviours for various protocol, it would be definitely be preferable 
to produce these documents in a scale of months, so the time period between 
the UDP specification and multicast would be minor.

  Geoff

At 09:29 PM 23/08/2004, Spencer Dawkins wrote:
I'm not disagreeing on the "work on unicast UDP first" strategy, but I do 
have a question.

If I understand the justification for BEHAVE, the idea is to have 
BCP-strength specifications that vendors and operators will use, and then 
(they will most likely) claim "BCP 110" (more likely "RFC 4112", but 
that's a NEWTRK problem) compliance.

If we don't work on multicast at this time, I think we're saying "we don't 
care if people break multicast now - if their NATs drop all multicast 
traffic, they can stilll say they comply with IETF BCPs for NAT, and 
that's OK".

Spencer
----- Original Message -----
From: <mailto:fluffy@xxxxxxxxx>Cullen Jennings
To: <mailto:audet@xxxxxxxxxxxxxxxxxx>Francois Audet ; 
<mailto:dwing@xxxxxxxxx>Dan Wing ; 
<mailto:ietf-behave@xxxxxxxxxxxxxxxxxxx>Behave ; 
<mailto:jiri@xxxxxxxxx>Jiri Kuthan
Sent: Sunday, August 22, 2004 8:49 PM
Subject: [Ietf-behave] UPD and Multicast scope

Given the advice we got at the meeting, I would be happiest to propose we 
do the "UDP Unicast" stuff in one of our first documents then do the 
"Multicast" stuff in a later document.
That said, I think that considering how our future work might break the 
UDP Unicast work is completely appropriate. We probably need some clue of 
how we might solve the multicast timeouts issues when we get to them and 
if that would require changers to the UDP document we need to contemplate 
that now.
I can see several discussion paths we might pursue:
   * treat multicast traffic differently
   * do outbound keep alives in multicast applications
   * update timeouts on inbound packets for unicast UDP

Cullen

_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 24 Aug 2004 21:37:20 -0700 (PDT)

On Thursday, August 19, Francois Audet wrote:

> I guess one question I have is, does Multicast work
> today with home NATs?

It's available as a feature on my 3-year-old Linksys NAT box, but I have
never tried using it so I don't know if it actually works.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 25 Aug 2004 13:50:00 -0700 (PDT)

Geoff wrote:

> Spencer, you seem to be taking that view that the period between these
> two documents would be an extended one - perhaps measured in
> geological eons ( :-) ). While that may indeed be a useful metric for
> measuring the progress of IETF documents these days, I'm not sure that
> it has to be this way, and in the case of writing down NAT behaviours
> and what is a reasonable set of such behaviours for various protocol,
> it would be definitely be preferable to produce these documents in a
> scale of months, so the time period between the UDP specification and
> multicast would be minor.

With that in mind, I believe we're attempting to write the following
documents in this yet-to-be-formed working group:

  1. base BEHAVE document for UDP, TCP, fragmentation, 
     and ICMP (based on draft-audet-nat-behave-00.txt)
  2. separate document for UDP multicast receivers
  3. separate document for IPsec initiators

Can we safely combine (1) and (3) without delaying things?  

-d