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

From: "Francois Audet" <[email-masked]>
Date: Fri, 10 Mar 2006 11:34:06 -0800 (PST)

That's fine with me.

But if there are specific statements that need to be altered to avoid
conflict
altogether, we should do it.

I don't have specific proposals on that.

> -----Original Message-----
> From: Pyda Srisuresh [mailto:srisuresh@xxxxxxxxx] 
> Sent: Friday, March 10, 2006 10:57
> To: Audet, Francois [SC100:3055:EXCH]; Dan Wing; Cullen 
> Jennings; Jiri Kuthan; Behave
> Subject: RE: [Ietf-behave] Re: ICMP behave draft
> 
> 
> 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
> 
> --- Francois Audet <audet@xxxxxxxxxx> wrote:
> 
> > 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 11:43:18 -0800 (PST)

OK. I am not aware of any statements that conflict. But, if there are, I agree,
that should be avoided.

regards,
suresh