Subject: RE: hop limit API question

From: Richard Draves <[email-masked]>
Date: Fri, 27 Aug 1999 14:27:19 -0700

> We've implemented the multicast behavior to match the IPv4 behavior
> just like Francis (loop back to any local members on the 
> sending interface
> if IPV6_MULTICAST_LOOP is set).
> 
> For unicast we make no checks thus packets would be transmitted with
> a zero hoplimit.

Hmm, at least for v4, the host requirements RFC 1122 section 3.2.1.7 says
that hosts MUST NOT send a datagram with a TTL of zero.

But it seems reasonable to allow loopback of packets (both unicast and
multicast) with a zero hop limit.

Rich
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Sat, 28 Aug 1999 11:37:40 +0200

=> I've tried to explain this point :
 - RFC 1122 section 3.2.1.7 refers to RFC 791 where this point is not.
 - in my TCP/IP Illustrated vol2 p1100 in the BSD compliance list there is:
  * MUST NOT send packet with TTL of 0.
    Partially: The IP layer (ip_output) in Net/3 does not check this
    requirement and relies on the transport layers not to construct an
    IP header with a TTL of 0. UDP, TCP, ICMP, and IGMP all select a
    nonzero TTL default value. The default value can be overridden by
    the IP_TTL option.

=> I agree. Do you believe there MUST be an explicit test for not-loopback
packets with 0 hop limit ? I think it doesn't matter (ie. the MUST should
be replaced by a SHOULD, the only case where packets with 0 hop limit
can be a problem is for brain-damaged routers with 0-1=255 !).

Regards

[email-masked]

PS: my intention is not to open a new MUST vs SHOULD war but I'd like
to know if I have to add the two line test in my ip6_output() function...
PPS: after more reflection, I think the IPV6_*CAST_HOPS setsockopt spec
is the good place to fix this problem :
 replace for IPV6_UNICAST_HOPS:
      x < -1:        return an error of EINVAL
      x == -1:       use kernel default
      0 <= x <= 255: use x
      x >= 256:      return an error of EINVAL
 by
      x < -1:        return an error of EINVAL
      x == -1:       use kernel default
      x == 0:        EINVAL error or kernel default ???
      0 < x <= 255:  use x
      x >= 256:      return an error of EINVAL
  because if the (unique!) destination of a packet is local then the hop
  limit doesn't matter.
keep the IPV6_MULTICAST_HOPS with a mention to the limitation for 0
hop limit (ie. Richard Draves' text).
It is very important to keep IPv4 multicast application programming style
for IPv6 because there is only a little documentation about how to build
multicast applications (Steve Deering's note in ipmulti distrib is the
best known (least unknow :-)) and of course there (still) are about IPv4.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------