Subject: Re: Last Call: IPv6 Node Information Queries to Proposed Standard

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 11 Sep 2000 02:19:31 +0900

>>>>> On Thu, 31 Aug 2000 12:36:10 -0400, 
>>>>> The IESG <[email-masked]> said:

> The IESG has received a request from the IPNG Working Group to consider
> IPv6 Node Information Queries
> <draft-ietf-ipngwg-icmp-name-lookups-07.txt> as a Proposed Standard.

> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by September 13, 2000.

I admit that I should've made comments on the draft earlier, but
please let me add a final (I hope this is final) comment.

The 07 draft defines TTL of an address used in the node information
messages as follows:

    The Responder must fill in the TTL field of the Reply with a
    meaningful value if possible.  That value should be one of the
    following.

        The remaining lifetime of a DHCP lease on the Subject Address;

        The remaining Valid Lifetime of a prefix from which the Subject
        Address was derived through Stateless Autoconfiguration [2461,
        2462];

        The TTL of an existing AAAA or A6 record which associates the
        Subject Address with the DNS Name being returned.
(page 8, Section 4.3)

Possible range of those TTLs are different:
According to draft-ietf-dhc-v6exts-12.txt defines, the Valid (lease)
lifetime of an IPv6 address configured by DHCPv6 is a 32bits integer
(in seconds). (I'm not sure if the value is signed or not, and if it
has some range only by the draft).

According to RFC 2461, the Valid lifetime of an IPv6 address through
stateless autoconfiguration is an unsigned 32bits integer (in
seconds), and the "all-1 value (0xffffffff)" has a special meaning,
i.e. infinity.

According to RFC 2181, the TTL value for a DNS record is an unsigned
integer from 0 to 2^31 - 1.

The easiest way to solve the ambiguity would be introduding an
additional field for the TTL field to specify the type of
TTL. However, this would break backward compatibility (again!)...
Currently, I'm not sure the best way, but we'll surely need some
clarification here.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Mon, 11 Sep 2000 17:40:28 +1100

Date:        Mon, 11 Sep 2000 02:19:31 +0900
    From:        JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
		 <[email-masked]>
    Message-ID:  <[email-masked]>

  | The easiest way to solve the ambiguity would be introduding an
  | additional field for the TTL field to specify the type of
  | TTL. However, this would break backward compatibility (again!)...
  | Currently, I'm not sure the best way, but we'll surely need some
  | clarification here.

Actually, the easiest way is just to define it as an unsigned integer
(values 0 .. 2^32 - 1) - with 0xffffffff defined specially if needed.

A negative TTL has no useful meaning, so even if the dhcpv6exts (the version
with the '-' instead of the 'p' in the draft name expired ages ago) draft is
intending to allow a negative value for the valid lease lifetime for some
reason, sending 0 in the node information query would be reasonable if given
negative input (though what a negative value would mean I have no idea ..
"you should have returned this address I am just giving you 30 minutes ago" ?).
That draft needs a better definition of this field.

Then all rational TTL values can be included - the DNS can only handle half
of what can be in the node information reply, but that's OK, what matters is
that the DNS response can be loaded into the node info field, not the other
way.

kre