Subject: RE: [Ietf-behave] Re: ICMP behave draft

From: "Francois Audet" <[email-masked]>
Date: Thu, 9 Mar 2006 10:06:13 -0800 (PST)

My suggestion would be that the authors clean up the drafts of any
overlapping material with completed work (i.e.,
draft-ietf-behave-nat-udp-04).

Otherwise, this is not helpful.

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Dan Wing
> Sent: Thursday, March 09, 2006 09:46
> To: 'Cullen Jennings'; 'Pyda Srisuresh'; 'Jiri Kuthan'; 'Behave'
> Subject: RE: [Ietf-behave] Re: ICMP behave draft
> 
> 
> 
> > At a casual glance (and I may be very wrong...) Some of these
> > requirements are already covered in the UDP draft. 
> 
> I made some comments on this draft to the authors so I'll 
> throw in a few thoughts on where there is some requirement 
> overlap that I noticed:
> 
> 
> 1. ietf-behave-nat-udp-04.txt, section 9, discusses ICMP 
> behavior.  In that section is REQ-12 which says:
> 
>    REQ-12: Receipt of any sort of ICMP message MUST NOT 
> destroy the NAT
>       mapping.
>       a) The NAT's default configuration SHOULD NOT filter 
> ICMP messages
>          based on their source IP address.
>       b) It is RECOMMENDED that a NAT support ICMP Destination
>          Unreachable messages.
> 
> which seems to overlap partially with REQ-2 in 
> srisuresh-behave-nat-icmp-01:
> 
>    REQ-2: A NAT device MUST transparently forward ICMP error packets
>    to the target end node, so long as the NAT has active mapping for
>    for the embedded payload. If the NAT does not have an active
>    mapping for the embedded payload, the NAT should silently drop the
>    ICMP error packet. In the case the ICMP error packet is originated
>    by a node in the private realm for which the NAT device has no
>    mapping, the NAT device MUST use its own IP address in the public
>    realm to translate the originating node IP address in the outer
>    IP header.
> 
> and overlaps completely with REQ-3 in srisuresh-behave-nat-icmp-01:
> 
>    REQ-3: While processing an ICMP error packet, a NAT device 
> MUST NOT 
>    refresh or delete the NAT Session that pertains to the embedded
>    payload within the ICMP error packet.
> 
> 
> 2. ICMP Don't Fragment handling.  ietf-behave-nat-udp-04 says:
> 
>    If the packet has DF=1, the NAT SHOULD send back an ICMP message
>    "fragmentation needed and DF set" message to the host as 
> described in
>    RFC 792 [2].
> 
>    If the packet has DF=0, the NAT SHOULD fragment the packet and send
>    the fragments, in order.  This is the same function a 
> router performs
>    in a similar situation RFC 1812 [5].
> 
> and ietf-behave-nat-udp-04 also says:
> 
>    REQ-13: A NAT MUST support fragmentation of packets larger 
> than link
>       MTU.
> 
> compared to srisuresh-behave-nat-icmp-01 which says:
> 
>    REQ-5: If DF bit is set on a transit IP packet and the NAT
>    device cannot forward the packet without fragmentation, the
>    NAT device MUST send a "Packet too big" ICMP message (ICMP
>    type 3, Code 4) with a suggested MTU back to the sender and
>    drop the original IP packet.
> 
> 
> 
> What is interesting is that 
> draft-srisuresh-behave-nat-icmp-01.txt has a different scope 
> and applies to both TCP, UDP, and ICMP bindings (an ICMP 
> binding is one that exists while you're doing a ping or an 
> ICMP-based traceroute (which is what Windows' "tracert" 
> does)), whereas -behave-nat-udp only applies to UDP bindings.  
> 
> I expect the TCP BEHAVE document will discuss ICMP behavior 
> for ICMPs that are associated with TCP flows in a manner 
> similar to what is in ietf-behave-nat-udp-04.
> 
> 
> Would it be valuable to scope an ICMP draft to discuss only 
> ICMP sessions -- that is, ICMP bindings that are created as a 
> result of running the ping utility or an ICMP-based 
> traceroute utility (such as "tracert.exe" on Windows)?
> 
> -d
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 10 Mar 2006 10:57:23 -0800 (PST)

Francois,

Please see my response to Dan on the Scope. In that I mentioned that I would be
happy to add a statement in the ICMP draft to the effect that ICMP requirements
in the TCP or UDP drafts should take precedence over the general ICMP
requirements stated in the ICMP draft. Hope that works for you. Please respond
if this would work for for you in the other thread (labelled "Scope of ICMP
draft"). Thanks.

regards,
suresh