Subject: RE: RFC 2460 issue

From: [email-masked]
Date: Tue, 28 Oct 2003 16:08:31 +0200

Hi Jari,

> Suresh Krishnan wrote:
> > Hi Alain,
> > 	Since the hop limit is analogous to TTL in IPv4 the answer should 
> > be no. But you will not find the answer in RFC 2460 as this was not 
> > covered in RFC 791. This should be covered in the node requirements draft 
> > (draft-ietf-ipv6-node-requirements-06.txt) that John is editing. I 
> > checked the draft but it did not have a section regarding this(analogous 
> > to RFC 1122 section 3.2.1.7). Maybe this can be added to that draft. I am 
> > curious as to why you would want to do that though.
> 
> I think we have agreed now that the node requirements document is
> not a place to list all updates and deficiencies of existing RFCs --
> those existing RFCs should be updated instead.

I agree.

John

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 28 Oct 2003 14:46:16 -0500 (EST)

On Tue, 28 Oct 2003 [email-masked] wrote:
Hi Jari/John,
  That sounds fine but it is not just RFC 2460 that needs to be updated 
but perhaps many others. Off the top of my head I know that RFC3493 needs 
to be updated since the IPV6_UNICAST_HOPS socket option now accepts 0 as a 
valid hop count. I really do not understand what a hop count of 0 implies 
and why we should bother updating the RFCs.

Regards
Suresh

---

From: Markku Savela <[email-masked]>
Date: Tue, 28 Oct 2003 22:21:14 +0200

> Off the top of my head I know that RFC3493 needs to be updated since
> the IPV6_UNICAST_HOPS socket option now accepts 0 as a valid hop
> count. I really do not understand what a hop count of 0 implies and
> why we should bother updating the RFCs.

Heh, yes. I too wondered about what I should do if application sets
TTL = 0. There are two choices

 a) Packets go to /dev/null (perhaps some obscure testing feature?)

 b) Just let packets with TTL=0 go out.

I chose (b), because

 - TTL is naturally checked only on fowarding, not when sending
   own packets out. Thus, any TTL just gets accepted and sent.

If packet with TTL=0 is for this node, it is accepted (again, because
TTL test is only for forwarding).

Forwarding decrements TTL and if result is 0 or < 0, packet dropped
(with appropriate ICMP if needed).

I'm happy with above semantics. I don't see any need to worry about it
too much.