Subject: Review of draft-wbeebee-on-link-and-off-link-determination-02

From: Suresh Krishnan <[email-masked]>
Date: Mon, 10 Mar 2008 17:07:45 -0400

Hi Folks,
   I read the latest version of the draft and it very clearly 
articulates the problem it is trying to address. Thanks for doing this. 
I have a few comments.

Section 1
=========

Change

"The reception of a Prefix Information Option (PIO) with the L-bit set
  and a non-zero valid lifetime creates (or updates the valid lifetime
  for an existing entry) in the prefix list. "

to

"The reception of a Prefix Information Option (PIO) with the L-bit set
  and a non-zero valid lifetime creates an entry (or updates the valid
  lifetime for an existing entry) in the prefix list."

Section 2 Steps 1-4
===================

It is not clear from the draft if steps 1-4 need to be followed by 
RFC2461 compliant hosts. My understanding is no, but feel free to 
correct me if I am wrong.

Section 2 Step 5.3
==================

"When address resolution fails, the host SHOULD send an ICMPv6 
Destination Unreachable message."

Where should the node send this message. Isn't it enough to indicate to 
the requesting application that the destination is not reachable using 
some kind of indication?

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

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 10 Mar 2008 17:40:01 -0400

Section 1
=========
Sure - no problem.

Section 2 Steps 1-4
===================
These steps are absolutely necessary.  They derive from RFC2461, but are
spread throughout and implied by the RFC.  Our goal is not to add new
requirements in this draft.  Our goal is simply to reiterate, in one
place, all the rules pertaining to the IPv6 Subnet Model so that
implementers and testers will be able to look in one place and quickly
understand the implications of the IPv6 Subnet Model.

Tatuya Jinmei already commented on this draft, writing that the
statement in the Security Consideration section should be written
earlier in the draft.  The statement in question is:

"As this document merely restates and clarifies RFC 4861, it does not
 introduce any new security issues."

We will add it again in the introduction section in order to reiterate
our draft's intentions.

Section 2 Step 5.3
==================

RFC 4861 describes the proper use of the ICMP destination unreachable
indication (including the destination, if any):

    "ICMP destination unreachable indication
               - an error indication returned to the original sender of
                 a packet that cannot be delivered for the reasons
                 outlined in [ICMPv6].  If the error occurs on a node
                 other than the node originating the packet, an ICMP
                 error message is generated.  If the error occurs on the
                 originating node, an implementation is not required to
                 actually create and send an ICMP error packet to the
                 source, as long as the upper-layer sender is notified
                 through an appropriate mechanism (e.g., return value
                 from a procedure call).  Note, however, that an
                 implementation may find it convenient in some cases to
                 return errors to the sender by taking the offending
                 packet, generating an ICMP error message, and then
                 delivering it (locally) through the generic error-
                 handling routines."

This "SHOULD" came from Alain Durand's RFC 4943.

- Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Suresh Krishnan
Sent: Monday, March 10, 2008 5:08 PM
To: [email-masked]
Subject: Review of draft-wbeebee-on-link-and-off-link-determination-02

Hi Folks,

Section 1
=========

Change

to

Section 2 Steps 1-4
===================

Section 2 Step 5.3
==================

Cheers
Suresh

---

From: Ralph Droms <[email-masked]>
Date: Mon, 10 Mar 2008 18:16:57 -0400

I think the term "subnet" should not be used in this document, and  
should be replaced with "prefix" or "link" throughout, as appropriate.

"subnet" is not defined in any of the base IPv6 RFCs, as far as I  
know.  The term doesn't appear at all in RFC 2460.    Two instances  
seem to have crept into RFC 4861, and four in RFC 4862.   
Interestingly, some of those instances of "subnet" should, in my  
opinion, be replaced with "prefix" and some with "link"...

...which gets to my point that "subnet" is an imprecise term and can  
have different meanings in different contexts.

In the interest of full disclosure, there is one instance of "subnet"  
in RFC 3315.  We should have used "prefix".

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Mon, 10 Mar 2008 18:26:04 -0400

Hm.  Looks like we used "subnet" seven times in RFC 3633.

And, we added a new interpretation, as we verbed subnet to mean  
"subdivide a prefix".

- Ralph

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Mar 2008 07:36:48 -0700

> have different meanings in different contexts.

I agree that "subnet" by itself is underspecified; in some cases it 
should just be a prefix. I don't think this document uses subnet" to 
mean "link".

However, I do think we should refer to "subnet prefix" in some places. 
If nothing else to make it easier for folks with an IPv4 background to 
understand what we are talking about. The "subnet prefix" term is 
specified in RFC 4291 (the addressing architecture) thus I don't think 
need to completely purge it.

In this vein I think it might make sense to expand the title of the 
draft to:
IPv6 subnet model: the relationship between links and subnet prefixes

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Mar 2008 07:57:44 -0700

> Section 2 Step 5.3

This is just restating what ICMPv6 says about sending icmp unreachables 
with code "address unreachable".

I suspect an host implementation when it is know that the packet was 
generated locally (i.e., TCP, UDP, etc sent the packet down to the IP 
layer) might instead use some implementation specific mechanism to 
deliver the error. But that would be a local matter not covered by any 
IETF standard.

    Erik

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 11 Mar 2008 17:35:32 -0400

> From: Erik Nordmark [mailto:[email-masked]] 
> 

I second this.

Actually, I don't see the IPv6 model being so different from the IPv4
model of subnets, as much as it is a generalization of the IPv4 model.
The term "subnet" even in IPv4 is somewhat misleading, ever since CIDR
was introduced, and yet it stuck. And everyone seems to understand it
pretty well.

To me, IPv6 assumes many possible IP addresses for any given interface.
Then again, IPv4 allows this too. And IPv6 allows link-local addresses,
which IPv4 also allows now (RFC 3927). And IPv6 gives an explicit
lifetime to each of the address prefixes, which IPv4 does not do
explicitly. But that doesn't mean that IPv4 subnets are immutable in
time, either.

It helps understanding IPv6 if we keep a common vocabulary, IMO.

Bert

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 11 Mar 2008 19:56:33 -0400

At Tue, 11 Mar 2008 07:36:48 -0700,

> need to completely purge it.

Actually, I've just realized the word "subnet" might be the source of
confusion.  I've looked at the FreeBSD's ifconfig source code to
recall why the default prefix length was chosen to be 64 and found the
following code fragment:

	if (explicit_prefix == 0) {
		/* Aggregatable address architecture defines all prefixes
		   are 64. So, it is convenient to set prefixlen to 64 if
		   it is not specified. */
		setifprefixlen("64", 0, s, afp);
		/* in6_getprefix("64", MASK) if MASK is available here... */
	}

Although the notion of "aggregatable address" was deprecated, I think
the sense of this comment could still apply if the implementor refers
to RFC4291.  That is, Section 2.5 gives the following structure

   |          n bits               |           128-n bits            |
   +-------------------------------+---------------------------------+
   |       subnet prefix           |           interface ID          |
   +-------------------------------+---------------------------------+

and states as follows:

   All Global Unicast addresses other than those that start with binary
   000 have a 64-bit interface ID field (i.e., n + m = 64),
(this means the subnet prefix is 64).

And, as others pointed out, since the notion of "subnet" is not really
clear, it's not surprising even if the implementor interprets a
"subnet prefix" as on-link prefix.

Along with the context of this draft, I believe an IPv6 address should
be considered at the "minimum" level as described in RFC4291:

   At a minimum, a node may
   consider that unicast addresses (including its own) have no internal
   structure:

   |                           128 bits                              |
   +-----------------------------------------------------------------+
   |                          node address                           |
   +-----------------------------------------------------------------+

If this makes sense, I'd propose revising bullet #2 of Section 2 as
follows:

   2.  The configuration of an IPv6 address, whether through IPv6
       stateless address autoconfiguration [RFC4862], DHCPv6
       [RFC3315], or manual configuration does not imply that any
       prefix is on- link.  This means the address should initially be
       considered the one having no internal structure as shown in
       [RFC4291].  A host is explicitly told that prefixes or
       addresses are on-link through the means specified in [RFC4861].

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 11 Mar 2008 22:36:44 -0400

Tatuya,

Thanks for digging up BSD code. Your suggestion for the extra one
sentence in bullet 2 in Section 2 of our drafts makes total sense. I
will add the new bullet suggested by you to the draft and also add
RFC4291 as a Normative Reference to the References section of our draft.

Thanks.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, March 11, 2008 7:57 PM
To: Erik Nordmark
Cc: IPV6 Mailing List; Ralph Droms (rdroms)
Subject: Re: Review of
draft-wbeebee-on-link-and-off-link-determination-02

Actually, I've just realized the word "subnet" might be the source of
confusion.  I've looked at the FreeBSD's ifconfig source code to recall
why the default prefix length was chosen to be 64 and found the
following code fragment:

	if (explicit_prefix == 0) {
		/* Aggregatable address architecture defines all
prefixes
		   are 64. So, it is convenient to set prefixlen to 64
if
		   it is not specified. */
		setifprefixlen("64", 0, s, afp);
		/* in6_getprefix("64", MASK) if MASK is available
here... */
	}

Although the notion of "aggregatable address" was deprecated, I think
the sense of this comment could still apply if the implementor refers to
RFC4291.  That is, Section 2.5 gives the following structure

   |          n bits               |           128-n bits            |

and states as follows:

   All Global Unicast addresses other than those that start with binary
   000 have a 64-bit interface ID field (i.e., n + m = 64), (this means
the subnet prefix is 64).

And, as others pointed out, since the notion of "subnet" is not really
clear, it's not surprising even if the implementor interprets a "subnet
prefix" as on-link prefix.

   At a minimum, a node may

   |                           128 bits                              |

---
JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Mar 2008 16:01:37 -0700

> (this means the subnet prefix is 64).

Yes, but that RFC describes how the IPv6 address space is structured.

>    consider that unicast addresses (including its own) have no internal

I think your added sentence is good but it might be better to add it in 
the introduction instead of in this bullet.

We could in addition say
	The fact that Global Unicast addresses other than those that
	start with binary 000 have a 64-bit interface ID field [RFC4291]
	does not imply that the 64 bit prefix should be considered
	on-link.

    Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 17 Mar 2008 13:52:43 -0700

At Thu, 13 Mar 2008 16:01:37 -0700,

> Yes, but that RFC describes how the IPv6 address space is structured.

I know, but my point is that the unclear definition around "subnet"
with this specific structure may let an implementor regard the 64-bit
prefix as on-link.

> the introduction instead of in this bullet.

That's fine, and I also agree with the addition below.  In fact, I've
been thinking my suggested text may still not be perfectly clear.
Yours is much better than mine in clarity.

---
JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Fri, 28 Mar 2008 13:11:41 -0400

Erik - thanks; I was not aware that "subnet prefix" is defined in RFC  
4291.  I'll read draft-wbeebee-on-link-and-off-link-determination with  
that definition in mind.

- Ralph

On Mar 11, 2008, at Mar 11, 2008,10:36 AM, Erik Nordmark wrote:
>> know.  The term doesn't appear at all in RFC 2460.    Two  
>> instances  seem to have crept into RFC 4861, and four in RFC  
>> 4862.   Interestingly, some of those instances of "subnet" should,  
>> in my  opinion, be replaced with "prefix" and some with "link"...
>> ...which gets to my point that "subnet" is an imprecise term and  
>> can  have different meanings in different contexts.
>
> However, I do think we should refer to "subnet prefix" in some  
> places. If nothing else to make it easier for folks with an IPv4  
> background to understand what we are talking about. The "subnet  
> prefix" term is specified in RFC 4291 (the addressing architecture)  
> thus I don't think need to completely purge it.
>