Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

From: Thomas Narten <[email-masked]>
Date: Thu, 03 Jul 2008 15:25:27 -0400

My. $.02.

Close to ready to ship.

Substantive:

>    In addition to the Prefix List, individual addresses are on-link if
>    they are the target of a Redirect Message indicating on-link, or the
>    source of a valid Neighbor Solicitation or Neighbor Advertisement
>    message.

Per list discussion, this last part should be dropped.

>    3.  On-link determination SHOULD NOT persist across IPv6 interface
>        initializations.  Note that section 5.7 of [RFC4862] describes
>        the use of stable storage for addresses acquired with stateless
>        address autoconfiguration with a note that the Preferred and
>        Valid Lifetimes must be retained if this approach is used.
>        However no RFC suggests or recommends retaining the on-link
>        prefixes.

Hmm. I agree that the current specs don't suggest doing this, but is
it forbidden or wrong? I.e., is caching on-link information any worse
than caching the generated addresses? The PIO has Lifetime fields, and
as long as they are honored... ANd indeed, that is what point 4
reinforces...

I don't see right off why rule 3 is needed.

>    5.  Newer implementations, which are compliant with [RFC4861] MUST
>        adhere to the following rules.  Older implementations, which are
>        compliant with [RFC2461] but not [RFC4861] may remain as is.  If
>        the Default Router List is empty and there is no other source of
>        on-link information about any address or prefix:

Hmm. When are we going to say implementations of 2461 should be fixed
and no longer support the "all destinations are on link?". Again, I
am not sure point 5 is appropriate to include here, other than perhaps
to point out that the 2461 behavior is deprecated.

Editorial:

> 1.  Introduction
> 
>    IPv4 implementations associate a netmask when an IPv4 address is
>    assigned to an interface.  That netmask together with the IPv4
>    address designates an on-link prefix.  Addresses that match this
>    prefix are viewed as on-link i.e., traffic to these addresses is not

Better:

   IPv4 implementations typically associate a netmask with an address
   when an IPv4 address is assigned to an interface. That netmask
   together with the IPv4 address designates an on-link prefix.
   Addresses that are covered by this prefix are viewed as on-link
   i.e., traffic to these addresses is not sent to a router.  See
   section 3.3.1 in [RFC1122]. Prior to the deployment of CIDR, an
   address's netmask could be derived directly from the address. In
   tha absence of specifying a specific netmask when assigning a
   address, some implementations would fall back to deriving the
   netmask from the class of the address.

>    2.  The configuration of an IPv6 address, whether through IPv6
>        stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315],
>        or manual configuration MUST NOT imply that any prefix is on-
>        link.  A host is explicitly told that prefixes or addresses are
>        on-link through the means specified in [RFC4861].  Note that this
>        requirement for manually configured addresses is not explicitly
>        mentioned in [RFC4861].
> 

Better (?):

   2.  The configuration of an IPv6 address, whether through IPv6
       stateless address autoconfiguration [RFC4862], DHCPv6
       [RFC3315], or manual configuration MUST NOT implicitely cause a
       prefix derived from that address to be treated as on-link.  A
       host considers a prefix to be on-link only through explicit
       means, such as those specified in [RFC4861] or via manual
       configuration.  Note that the requirement for manually
       configured addresses is not explicitly mentioned in [RFC4861].

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 3 Jul 2008 16:35:36 -0400

Thomas,

Thanks for the quick reply and review.  Please see in line below between
"<hs>" and "</hs>". 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Thomas Narten
Sent: Thursday, July 03, 2008 3:25 PM
To: Brian Haberman
Cc: Bob Hinden; [email-masked]
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

My. $.02.

Close to ready to ship.

<hs>Done. I had sent an email today saying the text has been removed.
What was removed is text between quotes below.
 ", or the source of a valid Neighbor Solicitation or Neighbor
Advertisement message."
</hs>

>        However no RFC suggests or recommends retaining the on-link

Hmm. I agree that the current specs don't suggest doing this, but is it
forbidden or wrong? I.e., is caching on-link information any worse than
caching the generated addresses? The PIO has Lifetime fields, and as
long as they are honored... ANd indeed, that is what point 4
reinforces...

<hs>True, but what if someone has manually configured an IPv6 address
with prefix length, what are the Lifetime values for such a prefix? I am
not sure what happens here. Why not be then explicit and include such a
bullet. Also, the subject of our draft is focused on on-link
determination so we added such a bullet for completeness sake since
RFC4862 mentions persistent data across initializations. It is RFC4861
that deals with on-link determination. So why not have RFC4861 have such
text for on-link determination related to persistent storage. 
</hs>

Hmm. When are we going to say implementations of 2461 should be fixed
and no longer support the "all destinations are on link?". Again, I am
not sure point 5 is appropriate to include here, other than perhaps to
point out that the 2461 behavior is deprecated.

<hs>We'd like to keep this bullet because as you said, we wanted to
point out deprecated behavior. Further host implementations are
sometimes really blind and issue NS for non-link-local address even when
the host has been signaled off-link or host needs to issue only an
ICMPv6 error. We wanted to make such things clear even in this bullet.
It may be better to keep the behavior lock, stock, and barrel in bullet
5. Not only does an ICMPv6 Destination Unreachable need to be issued,
the host cannot issue an NS to resolve a non-link-local destination.
Further folks were also not sure where is the ICMPv6 Destination
Unreachable headed to even after RFC4943 has been published before our
draft? We made it very clear in this bullet 5.
</hs>

Better:

   the absence of specifying a specific netmask when assigning a

<hs>Yes, it is better - thanks! I have no problem with using it. 
    Hopefully Wes and Erik will not disagree with me.
</hs>

>        stateless address autoconfiguration [RFC4862], DHCPv6
[RFC3315],

Better (?):

<hs>Yes, this is better too - thanks again. I have no problem with using
it.

Appreciate the quick review before a long weekend.

Have a good one.

Hemant
</hs>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 3 Jul 2008 17:05:22 -0400

Thomas,

Sorry, I forgot one item that Wes just reminded me of. Earlier in the
day I had emailed out our new text for bullet 2 that has this new line:

"The source of an ND message is no longer used for on-link
determination, which is a change from [RFC4861]."

So the new bullet 2 that you suggested in snipped below followed by our
suggestion to add the line above to the bullet.

Better?

 2.  The configuration of an IPv6 address, whether through IPv6
       stateless address autoconfiguration [RFC4862], DHCPv6
       [RFC3315], or manual configuration MUST NOT implicitly cause a
       prefix derived from that address to be treated as on-link.  A
       host considers a prefix to be on-link only through explicit
       means, such as those specified in [RFC4861] or via manual
       configuration. The source of an ND message is no longer used 
       for on-link determination, which is a change from [RFC4861]. 
       Note that the requirement for manually configured addresses is 
       not explicitly mentioned in [RFC4861]. 

Thanks.

Hemant 

-----Original Message-----

My. $.02.

Close to ready to ship.

Better:

[RFC3315],

Better (?):

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Thu, 3 Jul 2008 17:07:34 -0400

Comments from me between <wb> and </wb> 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hemant Singh (shemant)
Sent: Thursday, July 03, 2008 4:36 PM
To: Thomas Narten; Brian Haberman
Cc: [email-masked]; Bob Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Thomas,

-----Original Message-----

My. $.02.

Close to ready to ship.

<wb>Note that we also pointed out later on that this is a change from
RFC4861 that is being made in this draft (which updates RFC4861).
</wb>

<wb>
What if there are cache-inconsistency problems, prefix renumbering, or
stale information?  I think it's better just to get rid of caching
on-link information in stable storage and get such information fresh
from RA's.  That way, administrators can better rationalize the behavior
of their network from the configured RA's.
</wb>

<wb>
We need to point out changes in behavior for people still following old
specifications so that they know what they need to change moving
forward.
</wb>

Better:

<wb>
I'm fine with this too.
</wb>

[RFC3315],

Better (?):

Have a good one.

Hemant
</hs>

<wb>I think this needs to be merged with our new text on this one which
points out 
that bullet 4 was explicitly removed from the definition of on-link
which was in 
RFC4861.
</wb>

---

From: Thomas Narten <[email-masked]>
Date: Thu, 03 Jul 2008 17:11:30 -0400

> determination, which is a change from [RFC4861]."

I object, because I do not believe 4861 really says this (if you look
across the document in totality) or was widely interpreted to say
this.

Until the recent notes from David Miles, I don't think anyone noticed
the bug. Certainly, I have seen no evidence that implementations
actually interpreted 4861 or its predecessors and actually did the
wrong thing when receiving an NS.

So, we can call certainly this a clarification, but I'd hesitate to
call it a change.

Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 3 Jul 2008 17:35:56 -0400

Thomas,

Will something like this work for you - we have replaced "change" with
"clarification".

[The source of an ND message is no longer used for on-link
determination, which is a clarification of bullet four of on-link
definition in Terminology section of [RFC4861].]

or 

[The source of an ND message is no longer used for on-link
determination, which is a clarification of on-link definition in
Terminology section of [RFC4861].]

I agree with you, no implementations have actually interpreted this
source address rule, but when folks like David notice the bug, folks
quote the definition of on-link in Terminology section of RFC4861. That
is why we thought of adding this line to our doc.

Thanks.

Hemant

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Thursday, July 03, 2008 5:12 PM
To: Hemant Singh (shemant)
Cc: Brian Haberman; Bob Hinden; [email-masked]
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

I object, because I do not believe 4861 really says this (if you look
across the document in totality) or was widely interpreted to say this.

Until the recent notes from David Miles, I don't think anyone noticed
the bug. Certainly, I have seen no evidence that implementations
actually interpreted 4861 or its predecessors and actually did the wrong
thing when receiving an NS.

So, we can call certainly this a clarification, but I'd hesitate to call
it a change.

Thomas

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 08 Jul 2008 18:50:27 -0700

At Thu, 3 Jul 2008 17:07:34 -0400,

> of their network from the configured RA's.

The same argument applies to caching the address, so it cannot be a
reason why we specifically prohibit the (on-link) prefix part of this
behavior.  

Actually, I see it can rather be harmful if we only prohibit the
on-link prefix part of this behavior.  Recall that the background
motivation of address caching is that it may help the situation of
a temporary outage of a router.  Now that we've deprecated the
'on-link by default' behavior, if the host doesn't also cache the
on-link information, the cached address is almost meaningless.

I'm not necessarily a fan of this tricky behavior, but prohibiting one
aspect of feature that will make the other aspect meaningless makes
logically no sense to me.

> I don't see right off why rule 3 is needed.

After all, such caching is a minor implementation detail.  I suspect
it doesn't do any harm in practice even if we remove this dicey
bullet.

Another note about the wording if still decide to keep this point:
this bullet does not correctly reflect the sense of the referred part
of RFC4862: "Note that section 5.7 of [RFC4862] describes the use of
stable storage for addresses acquired with stateless address
autoconfiguration..."  The intent of Section 5.7 of RFC4862 was not to
"describe" this behavior.  It was written because there was one known
implementation that supports this behavior and we thought it might be
useful to make note **just in case** other implementations want to do
the same thing.  This is why this section uses weak wording such as
"An implementation ... may want to retain..." and makes an explicit
note of "Further details on this kind of extension are beyond the
scope of this document."

As stated above, I'd rather suggest remove this bullet, in which case
this concern will be resolved automatically.  But if we keep it, I'd
like the wording to reflect the original intent of RFC4862.

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 08 Jul 2008 19:32:20 -0700

At Thu, 3 Jul 2008 17:35:56 -0400,

> Terminology section of [RFC4861].]

I object to this type of change (I have an alternate proposal.  See
the end of this message).

> is why we thought of adding this line to our doc.

First off, I believe we should be more careful before "deprecating"
this rule:

                    - any Neighbor Discovery message is received from
                      the address.

As an implementor, I've been aware of the non-trivial flavor of this
on-link condition, and have noticed it creates tricky corner cases.
But I've always thought it's intentional, rather than a "bug".
Although I was not 100% sure in which case this rule is expected to be
used, I've imagined it might be useful in a router-less network (as we
briefly discussed in a different thread) or some NBMA network.

BSD variants have in fact supported this behavior for years: I've just
tested this with a FreeBSD 7.0 box and confirmed it (that is, if that
host receives an NS from an address that is not covered by "on-link"
prefixes advertised by RAs, it will create a specific neighbor cache
entry for that address).  I've also quickly checked that Linux
(seemingly) supports this behavior, too.

I also suspect there may even be a TAHI test item that requires this
behavior (since it's tricky, and TAHI tests check tricky behaviors "by
definition":-).  If my guess is correct, there will be other
implementations that support this behavior to qualify for an "IPv6
ready logo" or something.

Now that I've seen the "inventors" of the neighbor discovery protocol
say it's a mistake and that I've also been wondering for what purpose
this rule is expected to be useful, I'd not necessarily be objecting
to the idea of deprecating this rule.  But since this will affect
(potentially many) existing implementations, this should be more
carefully and explicitly discussed with the implementors who have
already supported the behavior.  Perhaps we could have this discussion
when we want to revise RFC4861 to the full STD, but it should not be
done in part of a branch thread on a derivative "clarification"
document.

(BTW, I've seen a "security" concern on this behavior in a different
thread.  I was not sure about whether it's a mere FUD or it has a
really serious new security implication, due to the lack of details,
but in any event I'd not buy that argument in this context.  Since ND
is a link-local protocol, any attack including this one must be
performed within the same link as the victim.  And once we consider
such a hostile environment, we already know the neighbor discovery as
a whole is just vulnerable to many serious attacks.  If we want to
counter this situation, we must deploy SEND; simply deprecating one
minor corner case doesn't help).

Now, going back to the wording of the "subnet model" document, I
suggest the following change to reflect this discussion:

From:
   In addition to the Prefix List, individual addresses are on-link if
   they are the target of a Redirect Message indicating on-link, or the
   source of a valid Neighbor Solicitation or Neighbor Advertisement
   message.  Note that Redirect Messages can also indicate an address is
   off-link.  Individual address entries can be expired by the Neighbor
   Unreachability Detection mechanism.

To:
   Section 2 of [RFC4861] defines the complete list of cases where an
   address is considered on-link.  Note, in particular, that Redirect
   Messages can also indicate an address is off-link.  Individual
   address entries can be expired by the Neighbor Unreachability
   Detection mechanism.

The key intent of the proposed change is to avoid the explicit
duplicate of the conditions.  So, even if we eventually make a
consensus on whether to deprecate any "on-link" conditions described
in RFC4861, probably in a context of revising the RFC, it will be less
likely that some implementors naively implement the would-be-obsolete
rule by simply referring to the "subnet model" document.  I also
believe this approach is generally desirable because this document
just tries to clarify some subtle points of RFC4861, rather than
making a substantial change to it.

---
JINMEI, Tatuya

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 9 Jul 2008 11:49:53 -0400

Tatuya,

This suggestion by you:

From:

To:

makes sense to us - we will take text from you - thanks. 

Further, it's better continuing discussion related to the 4th bullet of
on-link definition from the Terminology section of RFC4861. We can
totally not touch it in our draft - that is what we will do. We will
also remove any mention of the source-address rule in bullet 2 of
section 2 of our draft.  That's closure on our draft for the last call.

However, we can start that 4th bullet discussion right now where I and
Wes will justify why we wanted the 4th bullet deprecated. Thomas has
been saying that as well. We will explain why we do.

You see, the data forwarding table on a host takes precedence over
ND-cache. The data forwarding table consults the Destination Cache. If
an IPv6 node is a router then the data forwarding table is called the
routing table. We router folks do not like the 4th bullet because we do
not want our routing table cache to be touched merely based on source
address of packets received by the router interface. You see, the 4th
bullet seems to only apply to a router-less network but if one starts
applying the rule to routers, that is wrong! There are other reasons too
that we do not like the 4th bullet - the reasons have been given in
emails to this mailer.

Hemant & Wes 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 08, 2008 10:32 PM
To: Hemant Singh (shemant)
Cc: Thomas Narten; [email-masked]; Brian Haberman; Bob Hinden
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

> Terminology section of [RFC4861].]

I object to this type of change (I have an alternate proposal.  See the
end of this message).

> quote the definition of on-link in Terminology section of RFC4861. 
> That is why we thought of adding this line to our doc.

I also suspect there may even be a TAHI test item that requires this
behavior (since it's tricky, and TAHI tests check tricky behaviors "by
definition":-).  If my guess is correct, there will be other
implementations that support this behavior to qualify for an "IPv6 ready
logo" or something.

Now that I've seen the "inventors" of the neighbor discovery protocol
say it's a mistake and that I've also been wondering for what purpose
this rule is expected to be useful, I'd not necessarily be objecting to
the idea of deprecating this rule.  But since this will affect
(potentially many) existing implementations, this should be more
carefully and explicitly discussed with the implementors who have
already supported the behavior.  Perhaps we could have this discussion
when we want to revise RFC4861 to the full STD, but it should not be
done in part of a branch thread on a derivative "clarification"
document.

(BTW, I've seen a "security" concern on this behavior in a different
thread.  I was not sure about whether it's a mere FUD or it has a really
serious new security implication, due to the lack of details, but in any
event I'd not buy that argument in this context.  Since ND is a
link-local protocol, any attack including this one must be performed
within the same link as the victim.  And once we consider such a hostile
environment, we already know the neighbor discovery as a whole is just
vulnerable to many serious attacks.  If we want to counter this
situation, we must deploy SEND; simply deprecating one minor corner case
doesn't help).

Now, going back to the wording of the "subnet model" document, I suggest
the following change to reflect this discussion:

From:

To:

The key intent of the proposed change is to avoid the explicit duplicate
of the conditions.  So, even if we eventually make a consensus on
whether to deprecate any "on-link" conditions described in RFC4861,
probably in a context of revising the RFC, it will be less likely that
some implementors naively implement the would-be-obsolete rule by simply
referring to the "subnet model" document.  I also believe this approach
is generally desirable because this document just tries to clarify some
subtle points of RFC4861, rather than making a substantial change to it.

---
JINMEI, Tatuya

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 9 Jul 2008 12:21:06 -0400

Tatuya,

Erik suggested some new text to us related to bullets 3 and 4 of on-link
definition in the Terminology section of RFC4861. He is busy this week -
we are sending this on his behalf. As you know bullet 4 is being debated
in 6man. Erik thinks even bullet 3 is suspect. We don't want such
suspect information to be lost in archived emails of 6man. So we added
the information to our draft. Please see the new paragraph from us:

               The on-link definition in the Terminology section of
[RFC4861] 
               defines the complete list of cases where an address is
considered on-link.
               Note, in particular, that Redirect Messages can also
indicate an address is off-link. 
               As of the writing of this document, bullets three and
four of the on-link
               definition are being debated and may need further
clarification.
               Individual address entries can be expired by the Neighbor
Unreachability 
               Detection mechanism.

Please let us know if the new text works for you?

Thanks,

Erik, Wes, and Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 08, 2008 10:32 PM
To: Hemant Singh (shemant)
Cc: Thomas Narten; [email-masked]; Brian Haberman; Bob Hinden
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

From:

To:

---
JINMEI, Tatuya

---

From: Thomas Narten <[email-masked]>
Date: Wed, 09 Jul 2008 21:29:40 -0400

Note: replying to a number of separate messages here...

> reason why we specifically prohibit the (on-link) prefix part of this

Exactly.

> on-link prefix part of this behavior.

Again, I agree.

Note also, that DNA approaches essentially "cache" information about
the configuration of an interface across interfaces going up and down
-- which is very similar to the type of caching you are proposing to
disallow.

There is nothing wrong with caching information (as long as it has not
expired) so long as one replaces it if updated information comes along
later.

So I continue to be unpersuaded by any of the discussion so far that
we should saying "don't do that". 

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Wed, 09 Jul 2008 21:43:00 -0400

Jinmei,

Thanks for teasing this discussion apart further. You've tweaked an
old memory to the surface. :-)

> briefly discussed in a different thread) or some NBMA network.

It was intentional. I'd just forgotten why. :-)

When NodeA issues a NS for NodeB, that usually means that NodeA has
traffic to send to NodeB, and NodeB will shortly thereafter send a
response packet back to/through NodeA. In IPv4, that requires both
sides issue ARPs independently. I.e., NodeA has to ARP for NodeB, and
NodeB then later has to ARP for NodeA. A total of 4 packets, 2 of them
broadcast.

With ND, we can short circuit the need for the second packet
exchange. When NodeA issues an NS for NodeB, NodeB (per the rule we
have been discussing) goes ahead and creates a Neighbor Cache Entry
for NodeA (i.e., from the source address of the NS). When NodeB then
generates a response packet, it doesn't need to do an additional NS/NA
exchange, because it already has an entry for the desired address.

See Section 7.2.3 of RFC 4861:

> 7.2.3.  Receipt of Neighbor Solicitations
> 
>    A valid Neighbor Solicitation that does not meet any of the following
>    requirements MUST be silently discarded:
> 
>     - The Target Address is a "valid" unicast or anycast address
>       assigned to the receiving interface [ADDRCONF],
> 
>     - The Target Address is a unicast or anycast address for which the
>       node is offering proxy service, or
> 
>     - The Target Address is a "tentative" address on which Duplicate
>       Address Detection is being performed [ADDRCONF].
> 
>    If the Target Address is tentative, the Neighbor Solicitation should
>    be processed as described in [ADDRCONF].  Otherwise, the following
>    description applies.  If the Source Address is not the unspecified
>    address and, on link layers that have addresses, the solicitation
>    includes a Source Link-Layer Address option, then the recipient
>    SHOULD create or update the Neighbor Cache entry for the IP Source
>    Address of the solicitation.  If an entry does not already exist, the
>    node SHOULD create a new one and set its reachability state to STALE
>    as specified in Section 7.3.3.  If an entry already exists, and the
>    cached link-layer address differs from the one in the received Source
>    Link-Layer option, the cached address should be replaced by the
>    received address, and the entry's reachability state MUST be set to
>    STALE.
> 
>    If a Neighbor Cache entry is created, the IsRouter flag SHOULD be set
>    to FALSE.  This will be the case even if the Neighbor Solicitation is
>    sent by a router since the Neighbor Solicitation messages do not
>    contain an indication of whether or not the sender is a router.  In
>    the event that the sender is a router, subsequent Neighbor
>    Advertisement or Router Advertisement messages will set the correct
>    IsRouter value.  If a Neighbor Cache entry already exists, its
>    IsRouter flag MUST NOT be modified.
> 
>    If the Source Address is the unspecified address, the node MUST NOT
>    create or update the Neighbor Cache entry.
> 
>    After any updates to the Neighbor Cache, the node sends a Neighbor
>    Advertisement response as described in the next section.

One could argue that the above should be tweaked to say "create an NCE
only if the source address of the NS is on-link per other
indications". But given that the NCE is not actually used, if that
address is not considered on-link, there is no harm in just leaving
things as they are. The specification as written does not seem to be
resulting in broken implementations.

Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 9 Jul 2008 22:06:00 -0400

The host has 4001:420:3800:809::/64 as a prefix in host PrefixList
because the RA sent this prefix as on-link. The host has cached on-link
determination for this prefix and the current lifetime of the prefix is
much longer than the time it takes the host to reboot. Now the host is
rebooted and during this reboot, the admin of the network renumbered the
prefix to expire and also configured a new RA where RA has no PIO. After
reboot, the host still continues to use this cached information because
the prefix hasn't timed out and host did not see the renumbering RA.
After reboot, when the host sees a new RA the host is supposed to update
information from. RFC4861 says to use union of information from
different RA's, except where MTU or Lifetime of a prefix is concerned,
to take the new information only. But the new RA has no PIO and hence no
Lifetime. So it gets murky. Do we keep a union of 4001:420:3800:809::/64
as on-link and all other non-link-local destinations as off-link due to
an RA with no PIO or do we consider the new RA with no PIO to signal
Lifetime for any non-link-local prefix as zero?

What if the cache gets corrupted and the corruption changes a few bits
in the cached prefix and even a reboot doesn't fix the changed bits. The
RA remains same between reboot. But a totally different prefix now
exists as on-link. Why is this not a problem?

Also interesting is the fact that Suresh Krishnan who is author of DNA
protocol and Chairs DNA blessed our bullet 3 on June 18th, 2008 to
prohibit caching of on-link determination but Thomas is reporting that
DNA proposes the caching we disallow. 

Hemant

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Wednesday, July 09, 2008 9:30 PM
To: JINMEI Tatuya / ????
Cc: Wes Beebee (wbeebee); Hemant Singh (shemant); Brian Haberman; Bob
Hinden; [email-masked]

> > <wb>
> > What if there are cache-inconsistency problems, prefix renumbering, 
> > or stale information?  I think it's better just to get rid of 
> > caching on-link information in stable storage and get such 
> > information fresh from RA's.  That way, administrators can better 
> > rationalize the behavior of their network from the configured RA's.
> > </wb>

Exactly.

Again, I agree.

Note also, that DNA approaches essentially "cache" information about the
configuration of an interface across interfaces going up and down
-- which is very similar to the type of caching you are proposing to
disallow.

So I continue to be unpersuaded by any of the discussion so far that we
should saying "don't do that". 

Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 9 Jul 2008 22:21:36 -0400

Thomas,

You said: One could argue that the above should be tweaked to say
"create an NCE only if the source address of the NS is on-link per other
indications". 

Right. Remember, Erik said to v6ops on the issue that David Miles raised
that if a host received an NA from a src-addr that does not exist in the
host's PrefixList, then the receiving host has to drop the NS. I also
said the same to David Miles saying ND is a link-local scoped protocol,
so how can an NS arrive in the network from a prefix that doesn't exist
in the receiving host's PrefixList? 

Frankly David's issue was a deliberate src-addr selection screw up by
the sending host. Anyhow, as you say, the bogus NCE causes no harm.
Let's think issues in this area some more. That is why I and Wes decided
we are not going to touch this rule in our subnet-model draft. We need
more consensus and discussion.

Hemant 

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Wednesday, July 09, 2008 9:43 PM
To: JINMEI Tatuya / ????
Cc: Hemant Singh (shemant); [email-masked]; Brian Haberman; Bob Hinden
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Jinmei,

Thanks for teasing this discussion apart further. You've tweaked an old
memory to the surface. :-)

When NodeA issues a NS for NodeB, that usually means that NodeA has
traffic to send to NodeB, and NodeB will shortly thereafter send a
response packet back to/through NodeA. In IPv4, that requires both sides
issue ARPs independently. I.e., NodeA has to ARP for NodeB, and NodeB
then later has to ARP for NodeA. A total of 4 packets, 2 of them
broadcast.

With ND, we can short circuit the need for the second packet exchange.
When NodeA issues an NS for NodeB, NodeB (per the rule we have been
discussing) goes ahead and creates a Neighbor Cache Entry for NodeA
(i.e., from the source address of the NS). When NodeB then generates a
response packet, it doesn't need to do an additional NS/NA exchange,
because it already has an entry for the desired address.

One could argue that the above should be tweaked to say "create an NCE
only if the source address of the NS is on-link per other indications".
But given that the NCE is not actually used, if that address is not
considered on-link, there is no harm in just leaving things as they are.
The specification as written does not seem to be resulting in broken
implementations.

Thomas

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 09 Jul 2008 22:24:05 -0700

At Wed, 9 Jul 2008 12:21:06 -0400,

> Please let us know if the new text works for you?

This text works for me (although I guess these new sentences would be
a very good target for the IESG to make a "discuss" comment - good
luck:-).

---
JINMEI, Tatuya

---

From: Thomas Narten <[email-masked]>
Date: Thu, 10 Jul 2008 09:52:29 -0400

>     The on-link definition in the Terminology section of [RFC4861]
>     considered on-link.  Note, in particular, that Redirect Messages
>     can also indicate an address is off-link.  As of the writing of
>     this document, bullets three and four of the on-link definition
>     are being debated and may need further clarification.

> Please let us know if the new text works for you?

It does not work for me.

Looking at the bullets 3 & 4:

>    on-link     - an address that is assigned to an interface on a
>                  specified link.  A node considers an address to be on-
>                  link if:
> 
>                     - it is covered by one of the link's prefixes (e.g.,
>                       as indicated by the on-link flag in the Prefix
>                       Information option), or
> 
>                     - a neighboring router specifies the address as the
>                       target of a Redirect message, or
> 
>                     - a Neighbor Advertisement message is received for
>                       the (target) address, or
> 

IMO, bullets 3 & 4 MUST NOT be taken to indicate an address is
on-link. Nowhere in the ND specification does receipt of an NA or NS
result in the creation of a Destination Cache Entry that overrides the
first two bullets. The first 2 bullets are the only way (excluding
manual configuration) that an address is indicated to be on-link.

Yes, there are cases where and NS will create or update a  Neighbor
Cache Entry, but that is NOT the same thing as indicating that the
address is on-link.

Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 10 Jul 2008 10:05:35 -0400

Thomas,

You say: " bullets 3 & 4 MUST NOT be taken to indicate an address is
on-link."

But the Terminology section and the on-link definition clearly say
either of bullets 3 and 4 signify that the address is on-link. I have
snipped the text of the definition below.

So are you saying bullets 3 and 4 need to change? Anyway, Tatuya is not
letting any change to RFC4861 in our draft. So why is our text not
acceptable when we say these bullets need discussion?

Hemant

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Thursday, July 10, 2008 9:52 AM
To: Hemant Singh (shemant)
Cc: [email-masked]; Bob Hinden; Brian Haberman; [email-masked]
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

> Erik suggested some new text to us related to bullets 3 and 4 of 
> on-link definition in the Terminology section of RFC4861. He is busy 
> this week - we are sending this on his behalf. As you know bullet 4 is

> being debated in 6man. Erik thinks even bullet 3 is suspect. We don't 
> want such suspect information to be lost in archived emails of 6man. 
> So we added the information to our draft. Please see the new paragraph

It does not work for me.

>                     - any Neighbor Discovery message is received from

IMO, bullets 3 & 4 MUST NOT be taken to indicate an address is on-link.
Nowhere in the ND specification does receipt of an NA or NS result in
the creation of a Destination Cache Entry that overrides the first two
bullets. The first 2 bullets are the only way (excluding manual
configuration) that an address is indicated to be on-link.

Thomas

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 10 Jul 2008 11:59:12 -0400

Hi Thomas,

> -- which is very similar to the type of caching you are proposing to

Ack. This is exactly what simple dna does. It temporarily sets all the 
cached address information to deprecated while seeking confirmation. If 
there is confirmation either using either an incoming RA or a solicited 
NA from a known router, the link information is reused.

Cheers
Suresh

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 10 Jul 2008 14:28:27 -0400

Thomas,

Are you ok with the new paragraph if we removed this sentence from it:

"As of the writing of this document, bullets three and four of the
on-link definition are being debated and may need further
clarification." 

Further, since Tatuya will not let us add any text that suggests new
rules over RFC4861, we cannot accommodate any discussion related to
bullet 3 and 4 of on-link definition in our draft.

Please reply ASAP.

Thanks.

Hemant

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Thursday, July 10, 2008 9:52 AM
To: Hemant Singh (shemant)
Cc: [email-masked]; Bob Hinden; Brian Haberman; [email-masked]
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

It does not work for me.

Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 10 Jul 2008 17:11:52 -0400

Thomas,

2nd ping. If you could please reply, that'd be great. I don't think the
ship will return back to port to discuss anything related to on-link
definition bullets three and four in our draft - that ship has sailed.
So now that we have agreed to removing the line mentioned in the email
chain below I hope you don't have anything objection to this para (from
Introduction section of our draft), do you?

   The on-link definition in the Terminology section of [RFC4861]
   defines the complete list of cases where an address is considered on-
   link.  Note, in particular, that Redirect Messages can also indicate
   an address is off-link.  Individual address entries can be expired by
   the Neighbor Unreachability Detection mechanism.

Thanks.

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hemant Singh (shemant)
Sent: Thursday, July 10, 2008 2:28 PM
To: Thomas Narten
Cc: Brian Haberman; Bob Hinden; [email-masked]
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Thomas,

Please reply ASAP.

Thanks.

Hemant

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Thursday, July 10, 2008 9:52 AM
To: Hemant Singh (shemant)
Cc: [email-masked]; Bob Hinden; Brian Haberman; [email-masked]
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

It does not work for me.

Thomas

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 11 Jul 2008 09:23:14 -0400

Sorry to reopen this, but do you think that the following clarification
could be added to the IPv6 Subnet Models draft to address bullets three
and four of the on-link definition in the Terminology section of RFC
4861:

"Since only the Neighbor Cache is updated with the source address of a
received ND packet or the target of an NA packet, and the Destination
Cache and Prefix List are not updated, an ND packet cannot indicate that
a destination is on-link in the absence of corresponding on-link prefix
information."

What does the WG think?

- Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hemant Singh (shemant)
Sent: Thursday, July 10, 2008 5:12 PM
To: Hemant Singh (shemant); Thomas Narten
Cc: [email-masked]; Brian Haberman; Bob Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Thomas,

Thanks.

Hemant 

-----Original Message-----

Thomas,

Please reply ASAP.

Thanks.

Hemant

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Thursday, July 10, 2008 9:52 AM
To: Hemant Singh (shemant)
Cc: [email-masked]; Bob Hinden; Brian Haberman; [email-masked]
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

It does not work for me.

Thomas

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 14 Jul 2008 03:22:44 -0700

> briefly discussed in a different thread) or some NBMA network.

Yes, I think both bullet three and bullet four where there for some 
(incomplete) thoughts about NBMA. But I can't see a case when they would 
be needed. The redirect to an on-link target seems to be sufficient.

> (seemingly) supports this behavior, too.

Did you verify that it in fact treats the source of the NS as on-link as 
a result?

I don't have an issue with creating a neighbor cache entry; that has no 
security implications because it does impact anything but the neighbor 
cache on the interface where the NS was received. The question is about 
on-link determination.
Thus will the source of the NS be treated as on-link? Is the behavior of 
the implementations different if the source of the NS falls in a prefix 
which is already considered on-link on some other interface?

> minor corner case doesn't help).

Unfortunately, RFC 4861 doesn't specific enough about on-link 
determination to say whether that is a global activity, or whether it is 
done per interface.
Appendix A focuses on default router selection on multihomed nodes.

How do different multihomed implementation handle on-link determination?

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 14 Jul 2008 03:42:48 -0700

> exchange, because it already has an entry for the desired address.

FWIW RFC 826 specifies exactly the same thing - learn from the source 
protocol address and hardware address so that only 2 ARP packets are needed.

The case where bullet three and four would potentially help is when 
there is a NMBA network and as a result no on-link prefixes, or when 
different nodes are configured with different on-link prefixes.

Let's look at those in turn.
NBMA:
-----

Host A and Host B have an empty on-link prefix list hence all packets 
are initially sent to a default router. The default routers are assumed 
to know (through magic) all the IP and L2 addresses of the nodes on the 
link.

Host A sends packet destined to B to the router. Router responds with a 
redirect.
When host B responds to A that packet also goes to the router and 
results in a redirect.
That results in both host A and host B knowing that they are on-link 
with no use of NA or NS, and no use of bullet 3 and bullet 4.

Differently configured hosts:
-----------------------------

Host A and host B are on the same link.
Host A has been configured with IP address P1:A and with on-link 
prefixes P1 and P2.
Host B has been configured with IP address P2:B and on-link prefix P2.
(Note that this requires manual configuration since RFC 4861/4862 can't 
create such a configuration.)

When A sends a packet to P2:B it will multicast a NS since it views P2 
as on-link.
Taking bullet 4 into account B will treat P1:A as on-link, thus a single 
NS/NA exchange is sufficient.

If we remove bullet 4 then B would respond by sending the packet to a 
default router. Presumably that router knows P1 is on-link (so it can 
forward the packet back out the link) hence it would send a redirect 
back to B telling B that P1:A is on-link.

Thus in the case of statically inconsistently configured hosts we do 
same 2 packets sent on the wire as a result of bullet 4.

I can't come up with a case where bullet 3 would make a difference.

    Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 17 Jul 2008 19:11:07 -0700

At Mon, 14 Jul 2008 03:22:44 -0700,

> Did you verify that it in fact treats the source of the NS as on-link as 

Yes.

> which is already considered on-link on some other interface?

Ah, that's an interesting point.  To be clear, you're asking about a
case like this

- the receiving node has two interfaces, I1 and I2
- the node regards prefix P as on-link on interface I1
- the node receives an NS from P::X on interface I2

right?  I've not tested that case, but according to the source code,
I guess the following will happen:

- if the node has already a neighbor cache entry for P::x on interface
  I1, it does nothing about the source address of that NS
- if the node does not have any neighbor cache entry for P::x on any
  interface, it will create a new neighbor cache entry on interface
  I2.

But, this is a tricky case, so I may be wrong.

---
JINMEI, Tatuya