Subject: AD review of draft-ietf-6man-subnet-model

From: Jari Arkko <[email-masked]>
Date: Fri, 19 Feb 2010 14:24:49 +0200

I have reviewed this draft. The draft is in good shape and a welcome
clarification. However, I had two small issues I wanted to talk about
before moving the draft to last call:

5. Hosts MUST verify that on-link information is still valid after
IPv6 interface re-initialization before using cached on-link
determination information. Failure to do so may lead to lack of
IPv6 network connectivity. For example, a host receives an RA
from a router with on-link prefix A. The host powers down.
During the power off, the router sends out prefix A with on-link
bit set and a zero lifetime to indicate a renumbering. The host
misses the renumbering. The host powers on and comes online.
Then, the router sends an RA with no PIO. The host uses cached
on-link prefix A and issues NS's instead of sending traffic to a
default router. The "Observed Incorrect Implementation Behavior"
section below describes how this can result in lack of IPv6
connectivity.

"... MUST verify ... before using ..." appears to be in conflict with
the DNA specification (draft-ietf-dna-simple, in IESG review). The DNA
specification suggests the use of NS/NA and RS/RA exchanges in parallel
to verify that previously seen network configuration is still in
effect. The question is whether reception of NA is sufficient for the
host to continue operations (even if it still waits for the RS and
re-configures the interface if it shows different information). My
understanding is that the DNA specification wants to let hosts do this.

I would suggest that the first sentence above could actually be written
like this, without sacrificing anything substantial:

Hosts MUST verify that on-link information is still valid after
IPv6 interface re-initialization.

This leaves room for different verification techniques, e.g., verifying
before usage or in parallel as DNA does.

In an access
concentrator network ([RFC4388]), a host receives a Router
Advertisement Message with no on-link prefix advertised. The host
incorrectly assumes an invented prefix is on-link and performs
address resolution when the host should send all non-link-local
traffic to a default router.

I am not sure I understand the "invented prefix" case above. Where does
the prefix information come from, if there is no prefix in the RA? Or
is this a prefix from some previous network, or assigned as a part of
some other exchange that is not mentioned here? The example seems
incomplete.

Jari

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 21 Feb 2010 18:47:12 -0600

6man folks,

Here is the reply we sent to Jari on Friday wrt to his review below.

Hi Jari,

Thanks for the review.  We agree with your first comment and will change
the sentence to:

"Hosts MUST verify that on-link information is still valid after IPv6
interface re-initialization."

As for the second comment, here are more details on the example and
after reading them, if you can suggest text to complete the example that
satisfies you, we can go from there.

> I am not sure I understand the "invented prefix" case above.

IPv4 address assignment API's typically assigns both an address and a
mask to an interface.  One common implementation mistake by those
familiar with IPv4 is to assume that an address carries a /64 prefix
length if that prefix length is not specified.  This typically happens
at the API level - "assume /64".  The "invented prefix" refers to the
idea that this /64 actually comes from nowhere on the network - it was
invented by the programmer in order to make his API seem to work.

However, in actuality, it doesn't work in NBMA links where everything is
off-link and the /128 is assigned via DHCPv6.  The poorly implemented
API will assume a /64 prefix length and packets will not be forwarded to
the default router, thus resulting in lack of connectivity.  Because we
have seen real implementations have this mistake, we have included it in
the document.

What do we need to say in the document to make this more explicit?

Thanks,

Hemant and Wes

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jari Arkko
Sent: Friday, February 19, 2010 7:25 AM
To: IETF IPv6 Mailing List; [email-masked]
Subject: AD review of draft-ietf-6man-subnet-model

"... MUST verify ... before using ..." appears to be in conflict with
the DNA specification (draft-ietf-dna-simple, in IESG review). The DNA
specification suggests the use of NS/NA and RS/RA exchanges in parallel
to verify that previously seen network configuration is still in effect.
The question is whether reception of NA is sufficient for the host to
continue operations (even if it still waits for the RS and re-configures
the interface if it shows different information). My understanding is
that the DNA specification wants to let hosts do this.

In an access
concentrator network ([RFC4388 <http://tools.ietf.org/html/rfc4388> ]),
a host receives a Router

I am not sure I understand the "invented prefix" case above. Where does
the prefix information come from, if there is no prefix in the RA? Or is
this a prefix from some previous network, or assigned as a part of some
other exchange that is not mentioned here? The example seems incomplete.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 26 Feb 2010 00:23:31 +0200

Hemant,

> I am not sure I understand the "invented
prefix" case above.

IPv4 address assignment API's typically
assigns both an
address and a mask to an interface.  One common implementation mistake
by
those familiar with IPv4 is to assume that an address carries a /64
prefix
length if that prefix length is not specified.  This typically happens
at
the API level - "assume /64".  The "invented prefix"
refers to the idea that this /64 actually comes from nowhere on the
network -
it was invented by the programmer in order to make his API seem to work.

However, in actuality, it doesn't work in
NBMA links
where everything is off-link and the /128 is assigned via DHCPv6.  The
poorly implemented API will assume a /64 prefix length and packets will
not be
forwarded to the default router, thus resulting in lack of
connectivity.
Because we have seen real implementations have this mistake, we have
included
it in the document.

What do we need to say in the document to
make this more
explicit?

Maybe you could just explain the above.

Please update the draft. I have in
parallel sent it to IETF Last Call due to how the IESG telechat
deadlines work; it would be good if you could get in the update in the
next couple of days so that other reviewers do not have the same
questions as I did.

Jari

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 25 Feb 2010 17:25:28 -0600

Sure, Jari, we will update the draft to a 08 in the next 1-3 days and
submit it.

Thanks much!

Hemant

From: Jari Arkko [mailto:[email-masked]] 
Sent: Thursday, February 25, 2010 5:24 PM
To: Hemant Singh (shemant)
Cc: IETF IPv6 Mailing List; [email-masked]
Subject: Re: AD review of draft-ietf-6man-subnet-model

Hemant,

Please update the draft. I have in parallel sent it to IETF Last Call
due to how the IESG telechat deadlines work; it would be good if you
could get in the update in the next couple of days so that other
reviewers do not have the same questions as I did.

Jari