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 nortel.com> 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-bounceslist.sipfoundry.org
> > [mailto:ietf-behave-bounceslist.sipfoundry.org] 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-behavelist.sipfoundry.org
> > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> >
> >
>
_______________________________________________
Ietf-behave mailing list
Ietf-behavelist.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/ietf-behave
|