Subject: RE: comments on draft-ietf-6man-ipv6-subnet-model-03

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 4 May 2009 13:37:11 -0400

Jinmei,

I have fixed the sections numbers in the email reply below and responded to your comments.  Please see in line below.

- Wes

-----Original Message-----
From: JINMEI Tatuya / 神明達哉 [mailto:[email-masked]] 
Sent: Wednesday, April 29, 2009 8:10 PM
To: Hemant Singh (shemant); Wes Beebee (wbeebee); [email-masked]
Cc: [email-masked]
Subject: comments on draft-ietf-6man-ipv6-subnet-model-03

Upon request from the author, I've reviewed the I-D, and here are my comments.

I have one top level comment: I'm okay with removing the following two bullets from the original "on-link" definition of RFC4861

          - a Neighbor Advertisement message is received for the
          (target) address, or
          - any Neighbor Discovery message is received from the address.

to address security concerns.  But then I'd like to further simplify the rule of processing incoming NSes by discarding ones if the source address is not on-link.  Removing the above bullets while allowing accepting incoming NSes from a non-on-link address (and responding to
them) could make implementation very tricky for very little benefit.

WB> We need to discuss this further with Erik and Thomas.

Some implementations have already adopted this "simplification" to address the security concern, and, realistically, I don't think we can convince the maintainer to cancel the change and introduce a trickier patch to support the very minor case.  The end result would be the same: we'll lose interoperability.  Of course, we could blame such implementations for being "non compliant", but IMO it's more productive to plug the tricky corner case as we'll probably never need it in practice.

Other technical comments:

- Section 1 doesn't explain the motivation of removing the last two
  bullets of on-link definition.  I actually expected such
  incompleteness because it was not in the original goal of this
  draft.  That's why I insisted that this part is in a separate
  document.

WB> I suspect that if we put this in another document, then that document would not be progressed.  We already have a vector to make this change - therefore, we can add the motivation to the introduction section for removing the last two bullets.  After all, it does have to do with the topic of on-link determination.

- Section 1:
  Due to the tricky implication on on-link vs being neighbor (see
  above), if we wanted to keep it (note that I'm against it) the
  following cannot hold:

     A host only performs address resolution for IPv6 addresses that are
     on-link.

  because the host would have to perform address resolution for a
  "neighbor" but not necessarily an on-link node.  (if we also remove
  the tricky implication, this can be automatically solved:-)

WB> I think the original intent is to remove the processing of NS for not on-link addresses (ie. I agree with you), but we would need to consult more members of the WG to see if that is backed by consensus....

- Section 2: the section title "Host Behavior" is not very indicative
   to me.

WB> This section refers to host behavior of note with respect to on-link determination, but does not specify any rules that the host should follow (those are reserved for the Host Rules section). 

- Section 2: I simply didn't understand the following paragraph at
  all.  Please elaborate (I guess I asked the same thing before and it
  hasn't improved)

   2.  Note that Redirects cannot signal that an address is off-link.
   [...]

WB> The fact that Redirects cannot signal that an address is off-link derives from an extremely subtle and non-obvious consequence of the application of the Redirect message processing rules in section 8.1.  It was so subtle, that we even missed it the first time until Thomas explained it to us.  A Redirect message is silently discarded if it does not have an IP source address that is the same as the current first-hop router for the specified ICMP Destination address.  This is the processing rule.   Proof by contradiction: If you wanted to construct a Redirect to signal that a destination which the host believes is on-link is actually off-link, then you would have to select an IP source address that matches the current first-hop router for the destination (which the host believes is on-link).  However, since the host believes the destination is on-link, the host will not forward the packet to any first-hop router (because it's on-link).  Therefore, no valid IP source address 
 can be chosen for the Redirect (because there is no first-hop router for the destination, because the host believes the destination is on-link). Contradiction!  Therefore, the assumption, that you can construct a Redirect to signal that what a host believes is an on-link destination is actually off-link, is false.

- Section 2, bullet 3.  I disagree with this bullet as stated above.
  I won't go into further details on this at the moment because it's a
  rather meta level issue.

- Section 2, bullet 6: I don't understand this at all.  Why is this
  mentioned?  Why only multicast?

WB> This was mentioned because the all-nodes link-scope multicast address FF02::1 can be used to map out all the nodes that are accessable on a link, and thus be used to determine on-link.  However, that is a different definition of on-link than RFC 4861 uses.  It may be applicable to MANET and other groups at IETF.  Therefore, for the sake of completeness on the topic of on-link determination, we chose to describe it here so that future IETF'ers who will expand Neighbor Discovery to include MANET may use it as reference.  However, upon another read of the text, it's clear that any reception of a link-local packet will yield the same definition - so we can drop the word "multicast" from this bullet.

- Section 2, bullet 7: this rule isn't enforceable.  I thought I
  already pointed it out before (please google it).

WB> Routers decrement the Hop Limit field.  Therefore, there is a Hop Limit (255) that exists that can be used to indicate that packet has not crossed a router.  Note, however, that ND Proxy explicitly keeps the Hop Limit the same, so this definition (especially in the presence of networks that use ND Proxy) yields a different notion of on-link than RFC 4861 and a different notion of on-link than reception of link-scoped packets.  Also, this fact has been mentioned by the MANET team - and I expect that they can use this notion as they explore what a "link" means in the MANET world.  Further, please note that this bullet is in the Host Behavior section and is treated as an observation for the benefit of those who will modify Neighbor Discovery in the future (the MANET/LOWPAN team), and is not an enforceable rule.  The rules are laid out in the Host Rules section.

- Section 3, last para:

   Using cached on-link determination information without first
   [...]

  This doesn't address my previous concern.  Besides, this is not
  really a "rule" even if it's in the "host rules" section.

WB> To make it a rule, how about we add the following text:
WB> Hosts MUST verify that on-link information is still valid after IPv6 interface re-initialization before using cached on-link determination information.
WB> What specifically is your previous concern?

- Section 6: I guess there should be a reference to the security
  problem (cert advisory or something).

WB> Sure - we can quote the CERT Advisory here - it'll help give people who read this document without having been involved in the previous conversations more context when reading the document.

Editorial comments:

- Section 1 first para
  s/a address/an address/
- Some of the acronyms should be expanded beforehand (ND, RA, etc)
- there are some redundant white spaces, e.g. "on- link" (should be
  on-link)
- Section 3, bullet 4, there seems to be an indentation problem:

          Similarly, the following text from section 6.2.5 of [RFC4861]

  I suspect it's not part of citation.

WB> Agreed.  We will fix all your editorial comments.
  
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 4 May 2009 15:34:01 -0400

> From: Wes Beebee (wbeebee) [mailto:[email-masked]] 

> WB> The fact that Redirects cannot signal that an address is 
> off-link derives from an extremely subtle and non-obvious 
> consequence of the application of the Redirect message 
> processing rules in section 8.1.  It was so subtle, that we 
> even missed it the first time until Thomas explained it to 
> us.  A Redirect message is silently discarded if it does not 
> have an IP source address that is the same as the current 
> first-hop router for the specified ICMP Destination address.  
> This is the processing rule.   Proof by contradiction: If you 
> wanted to construct a Redirect to signal that a destination 
> which the host believes is on-link is actually off-link, then 
> you would have to select an IP source address that matches 
> the current first-hop router for the destination (which the 
> host believes is on-link).  However, since the host believes 
> the destination is on-link, the host will not forward the 
> packet to any first-hop router (because it's on-link).  
> Therefore, no valid IP source address 
>  can be chosen for the Redirect (because there is no 
> first-hop router for the destination, because the host 
> believes the destination is on-link). Contradiction!  
> Therefore, the assumption, that you can construct a Redirect 
> to signal that what a host believes is an on-link destination 
> is actually off-link, is false.

Can't the explanation be simpler?

A redirect is sent by a first hop router back to the sending host.
However, if the sending host thinks that the destination address of its
packet is on-link, it will not send the packet to a router. No router in
the path --> no one to generate a redirect.

Bert

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 4 May 2009 16:47:59 -0400

Jinmei,

Please see in line below between "<hs>" and "</hs>" for some more closure over what Wes closed in his email to you.

>I have one top level comment: I'm okay with removing the following two
>bullets from the original "on-link" definition of RFC4861

>to address security concerns.  But then I'd like to further simplify
>the rule of processing incoming NSes by discarding ones if the source
>address is not on-link.  Removing the above bullets while allowing
>accepting incoming NSes from a non-on-link address (and responding to

<hs>
We have discussed this issue again between myself and Wes and I see no reason to change or augment any text in our draft.  Please read bullet 3 of Section 2 in our draft again including the Conceptual Sending Algorithm in RFC 4861.  The ND-cache does not modify the data forwarding table of any ipv6 node and in light of this fact, there is nothing tricky we see if a host accepted an NS with a not on-link source and also replied to this NS as per RFC 4861 and the bullets 3 and 4 of on-link definition are deprecated.
</hs>

>Some implementations have already adopted this "simplification" to
>address the security concern, and, realistically, I don't think we can
>convince the maintainer to cancel the change and introduce a
>trickier patch to support the very minor case.  The end result would
>be the same: we'll lose interoperability.  Of course, we could blame
>such implementations for being "non compliant", but IMO it's more
>productive to plug the tricky corner case as we'll probably never need
>it in practice.

<hs>
The reason for accepting an NS message with not on-link source is to allow the Neighbor Cache's to be as full as possible to save having to do unnecessary address resolutions.  This has been clarified in bullet 3 of section 2 in our draft - see specifically the paragraph in bullet 3 that begins with this sentence: "The intention of the above feature is to add an address...". This does not cause an on-link determination problem, since a host only performs address resolution for IPv6 addresses that are on-link.  The reason that this works in practice is because RFC 4861-compliant implementations will have a separate Prefix List, Destination Cache, and Neighbor Cache.  Further, the Prefix List and Destination Cache are used to determine on-link status before the Neighbor Cache is consulted.
</hs>

>  the tricky implication, this can be automatically solved:-)

<hs>
I don't see anything tricky, nor do I see any reason for the statement above to not hold.  One has to understand the Conceptual Sending Algorithm in RFC 4861. If a host is to send a packet out, the Destination Cache is looked up for the destination IPv6 addr.  If the Destination Cache doesn't have the destination IPv6 addr, then the next-hop determination process is invoked that will first check the Prefix List for the destination IPv6 addr to map to any prefix in the Prefix List. If the destination addr matches a prefix in the Prefix List, then the destination is considered on-link.  Once the destination has been deemed to be on-link, the ND-cache is looked up to see if a L2 to L3 mapping exists so that the packet can be sent out to the next hop.  If the ND-cache doesn't have the destination address, then an address resolution is invoked.  Therefore, according to the Conceptual Sending algorithm described above, when the address resolution is issued, it has been already esta
 blished the destination is on-link.  The statement in the Introduction section is summarizing this fact.  
</hs>

Thanks,

Hemant

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 04 May 2009 14:50:09 -0700

One quick response first...

At Mon, 4 May 2009 16:47:59 -0400,
"Hemant Singh (shemant)" <[email-masked]> wrote:

> I don't see anything tricky, nor do I see any reason for the
> statement above to not hold.
...

Whether it's tricky or not (admittedly it's a subjective term), the
statement doesn't really hold.  Consider the following example:

- There is a host X.  X has a global address P::X, but has no
  information about on-link prefixes (for X, only link-local addresses
  can be considered on-link).  Note that even P::/plen is not
  considered an on-link prefix for X.
- There is another host Y with a global address P::Y.  Y somehow knows
  P::X is a neighbor of it.  Y also somehow knows the link-layer
  address of P::X.
- Y sends an NS to P::X without link-layer source address option, with
  the source address being P::Y.
- X tries to respond to the NS with NA.  The NA must be sent to P::Y.
  But since X doesn't know the link-layer address of P::Y, it first
  needs to perform address resolution.  On the other hand, according
  to the revised "on-link" definition, P::Y is not considered
  "on-link" (for X).

---
JINMEI, Tatuya

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 5 May 2009 10:11:33 -0400

Jinmei,

Sorry, I don't consider your example as valid because there is at least one step in your example's sequence of events that is invalid.  That step is mentioned below in quotes

"- Y sends an NS to P::X without link-layer source address option, with
  the source address being P::Y."

According to RFC 4861, a mcast NS MUST include the src link-layer option. So if the NS in your example was a mcast NS with no source link-layer option, then the NS is invalid.  Further, if your NS is a unicast NS which is a NUD message, then the L2 link-layer address of Y is available to X when X receives the unicast NUD message.

Hemant

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 05 May 2009 08:11:41 -0700

At Tue, 5 May 2009 10:11:33 -0400,
"Hemant Singh (shemant)" <[email-masked]> wrote:

> Sorry, I don't consider your example as valid because there is at
> least one step in your example's sequence of events that is invalid.
> That step is mentioned below in quotes
> 
> According to RFC 4861, a mcast NS MUST include the src link-layer
> option. So if the NS in your example was a mcast NS with no source
> link-layer option, then the NS is invalid.  Further, if your NS is a
> unicast NS which is a NUD message, then the L2 link-layer address of
> Y is available to X when X receives the unicast NUD message.

It's of course unicast (note the "to P::X").  BTW I don't understand
this part: "the L2 link-layer address of Y is available to X when X
receives the unicast NUD message."  Why is this ensured?  For example,
X may have just been rebooted and its neighbor cache may be empty.

---
JINMEI, Tatuya

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Tue, 5 May 2009 11:16:02 -0400

> It's of course unicast (note the "to P::X").  BTW I don't understand this part: "the L2 link-layer address of Y is available to X when X receives the
> unicast NUD message."  Why is this ensured?  For example, X may have just been rebooted and its neighbor cache may be empty.

That's because the address that you need is contained in the NUD packet itself.

- Wes

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 05 May 2009 09:33:50 -0700

At Tue, 5 May 2009 11:16:02 -0400,
"Wes Beebee (wbeebee)" <[email-masked]> wrote:
> 
> > It's of course unicast (note the "to P::X").  BTW I don't
> > understand this part: "the L2 link-layer address of Y is available
> > to X when X receives the unicast NUD message."  Why is this
> > ensured?  For example, X may have just been rebooted and its
> > neighbor cache may be empty.

> That's because the address that you need is contained in the NUD

??? Do you mean the responding host extracts the link-layer address
from the L2 header and uses it to send the NA?  And if so, are you
arguing that the responding node in question must behave that way to
keep this rule?

:     A host only performs address resolution for IPv6 addresses that are
:     on-link.

---
JINMEI, Tatuya

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Tue, 5 May 2009 16:23:57 -0400

I guess RFC 4861 doesn't go so far as to require that:

   "Because unicast Neighbor Solicitations are not required to include a
   Source Link-Layer Address, it is possible that a node sending a
   solicited Neighbor Advertisement does not have a corresponding link-
   layer address for its neighbor in its Neighbor Cache.  In such
   situations, a node will first have to use Neighbor Discovery to
   determine the link-layer address of its neighbor (i.e., send out a
   multicast Neighbor Solicitation)."

Which gives us three ways to solve this problem:

1) Amend "A host only performs address resolution for IPv6 addresses that are on-link." to say "A host only performs address resolution for IPv6 addresses that are on-link or possibly in response to an NUD message without a link-layer address option with an L2 source address that is unavailable to the ND stack."

2) Require hosts to extract the L2 header of the NS when sending the NA (which goes beyond RFC 4861) when the link-layer address option is not supplied in unicast NS messages.

3) Drop incoming NS's for addresses which are not already deemed to be on-link.

The advantage of #1 over #3 is that #1 allows a node to receive traffic from a source that is not deemed on-link by the node whereas #3 discourages such traffic.  

- Wes

-----Original Message-----
From: JINMEI Tatuya / 神明達哉 [mailto:[email-masked]] 
Sent: Tuesday, May 05, 2009 12:34 PM
To: Wes Beebee (wbeebee)
Cc: Hemant Singh (shemant); [email-masked]; [email-masked]
Subject: Re: comments on draft-ietf-6man-ipv6-subnet-model-03

At Tue, 5 May 2009 11:16:02 -0400,
"Wes Beebee (wbeebee)" <[email-masked]> wrote:
> > receives the unicast NUD message."  Why is this ensured?  For 
> > example, X may have just been rebooted and its neighbor cache may be 
> > empty.

> That's because the address that you need is contained in the NUD 

??? Do you mean the responding host extracts the link-layer address from the L2 header and uses it to send the NA?  And if so, are you arguing that the responding node in question must behave that way to keep this rule?

---
JINMEI, Tatuya

---

From: Thomas Narten <[email-masked]>
Date: Wed, 06 May 2009 13:28:03 -0400

> to address security concerns.

> But then I'd like to further simplify the rule of processing
> incoming NSes by discarding ones if the source address is not
> on-link.

I would be concerned with doing this, because it would lead to failure
cases in situations that I believe will happen in practice. That is,
it would make ND less robust than it is today or needs to
be. Specifically, such a rule would result in Node A not being able to
communicate with Node B, if for some reason Node A thought B was
on-link (and it really is), but Node B for some reason thinks it is
not on-link (whatever it means for a node to think its own address is
not on-link) and thus refuses to respond to a perfectly legitmate NS.

I don't see a good reason to ignore an NS from a neighbor asking about
a target address that is assigned to my interface. Not responding to
such a message could result in loss of connectivity. Sure, you can
argue this is a misconfiguration, but it could also result when RAs
aren't being delivered reliably, and one node has received a
particular RA, but another node has not, so they have differing
information. Or, node A may have been manually configured to assume
node B as on-link (and it is in fact).

> Removing the above bullets while allowing accepting
> incoming NSes from a non-on-link address (and responding to them)
> could make implementation very tricky for very little benefit.

I don't understand this. Nodes should be responding to NS queries for
target addresses that are assigned to the receiving interface. There
is no need for a node to even bother knowing whether that address is
considered "on-link" as a result of PIO options. There just isn't a
reason to do so (and it would be more work!). If someone asks about
one of the addresses you have assigned, just respond Why would you
not?

>   draft.  That's why I insisted that this part is in a separate

This is covered in Section 3. Arguably, that text could be made more
clear. Is your concern with the location of the motivation, or the
content?

>   the tricky implication, this can be automatically solved:-)

I must be missing something. One only runs ND on an address when
sending a packet to an address, and the Conceptual Sending Algorithm
indicates the address is on-link. Right? 

>    2.  Note that Redirects cannot signal that an address is off-link.

OK, how about the following text

OLD:

   2.  Note that Redirects cannot signal that an address is off-link.
       In section 8.1 of [RFC4861], a Redirect message is silently
       discarded if it does not have an IP source address that is the
       same as the current first-hop router for the specified ICMP
       Destination Address.  An ICMP Destination Address on the same
       link would have no current first-hop router.  Any Redirect
       message received could not have an IP source address that is the
       same as the current (null) first-hop router, so the Redirect MUST
       be dropped.

NEW:

   2.  Note that Redirect Messages do not contain sufficient
       information to signal that an address is off-link. Rather, they
       indicate a preferred next-hop that is a more appropriate
       choice to use than the originator of the Redirect. That
       alternate next-hop may be the destination itself (in which case
       packets would flow directly to a neighbor), or a router closer
       the destination. Note, however, that the redirect message
       itself does not contain sufficient information to distinguish
       these cases. But that does not matter, because the receiver of
       such  a message does the same in either case, updating its
       Neighbor Cache as defined in Section 8.1 of [RFC4861].

>   mentioned?  Why only multicast?

This section says:

   6.  Note that the receipt of a link-local IPv6 multicast packet which
       is not an ND packet indicates direct reachability on a link, but
       is not specifically treated by [RFC4861].

I also don't know what this is trying to say or why it needs to be
said. Can we just remove it?

>   already pointed it out before (please google it).

This section says:

   7.  Note that the receipt of a packet with the Hop Limit field
       unchanged (the Hop Limit could be specified in a packet-type
       specific document) which is not an ND packet indicates direct
       reachability on a link, but is not specifically treated by
       [RFC4861].

I don't understand what this paragraph is trying to say or why it
needs to be said, so I'd support removing it.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Wed, 06 May 2009 13:35:30 -0400

>   to the revised "on-link" definition, P::Y is not considered

OK. Now I remember your concern from an earlier thread. :-)

One thing that is missing from the entire ND discussion (and I would
say is just assumed and has been for a long time) is that ND is scoped
to a single link (just like ARP is). All NS responses are assumed to
be sent out the same interface on which the corresponding query was
received. There is no need to use normal IP routing when responding to
a NS query. Indeed, as you highlight above, doing so may result in
some failure scenarios.

I think the correct fix is to just state the above, in the sense that
that is what the necessary behavior needs to be. How that is
implemented (so long as it does the above) is not something the spec
needs to say anything about.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Wed, 06 May 2009 13:50:03 -0400

> Which gives us three ways to solve this problem:

None of which are acceptable. :-)

> 1) Amend "A host only performs address resolution for IPv6 addresses
>  that are on-link." to say "A host only performs address resolution
>  for IPv6 addresses that are on-link or possibly in response to an
>  NUD message without a link-layer address option with an L2 source
>  address that is unavailable to the ND stack."

This would be too complicated.

> 2) Require hosts to extract the L2 header of the NS when sending the
>  NA (which goes beyond RFC 4861) when the link-layer address option
>  is not supplied in unicast NS messages.

No. we designed ND to have LL option precisely to avoid needing to do
this, as it is problematic in some implementations and is a layer
violation.

> 3) Drop incoming NS's for addresses which are not already deemed to

No, for reasons outlined in an earlier note.

Lets try a different approach:

4) ND (like ARP) is scoped to a single link/interface. All responsese
to ND queries MUST be sent back out onto the same link.

>   to the revised "on-link" definition, P::Y is not considered

By definition, all NAs must go out onto the same interface on which
they were received. By this rule, one would know in trying to respond
that one did not have the LL address for P::Y, one would know which
interface the destination is on, and one could send out an NS on that
interface. Things would work.

Going through a node-wide IP routing table (with multiple interfaces,
etc.)  would (in this case) lead to the wrong result. I could imagine
other scenarios where going through the routing table would lead to
the wrong result.

Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 6 May 2009 14:28:30 -0400

Thomas,

Did you see the reply Wes gave to respond to bullets 6 and 7 of section 2 to the mailer?  Anyway, please see in line below where I have snipped in quotes what Wes explained bullets 6 and 7 were about.  

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Wednesday, May 06, 2009 1:28 PM
To: JINMEI Tatuya / 神明達哉
Cc: Hemant Singh (shemant); Wes Beebee (wbeebee); [email-masked]; [email-masked]
Subject: Re: comments on draft-ietf-6man-ipv6-subnet-model-03

>said. Can we just remove it?

"WB> This was mentioned because the all-nodes link-scope multicast address FF02::1 can be used to map out all the nodes that are accessible on a link, and thus be used to determine on-link.  However, that is a different definition of on-link than RFC 4861 uses.  It may be applicable to MANET and other groups at IETF.  Therefore, for the sake of completeness on the topic of on-link determination, we chose to describe it here so that future IETF'ers who will expand Neighbor Discovery to include MANET may use it as reference.  However, upon another read of the text, it's clear that any reception of a link-local packet will yield the same definition - so we can drop the word "multicast" from this bullet."

>needs to be said, so I'd support removing it.

"WB> Routers decrement the Hop Limit field.  Therefore, there is a Hop Limit (255) that exists that can be used to indicate that packet has not crossed a router.  Note, however, that ND Proxy explicitly keeps the Hop Limit the same, so this definition (especially in the presence of networks that use ND Proxy) yields a different notion of on-link than RFC 4861 and a different notion of on-link than reception of link-scoped packets.  Also, this fact has been mentioned by the MANET team - and I expect that they can use this notion as they explore what a "link" means in the MANET world.  Further, please note that this bullet is in the Host Behavior section and is treated as an observation for the benefit of those who will modify Neighbor Discovery in the future (the MANET/LOWPAN team),"

Thanks,

Hemant

---

From: Thomas Narten <[email-masked]>
Date: Wed, 06 May 2009 14:58:02 -0400

> Did you see the reply Wes gave to respond to bullets 6 and 7 of
> section 2 to the mailer?  Anyway, please see in line below where I
> have snipped in quotes what Wes explained bullets 6 and 7 were
> about.

Yes, I did see it.

> "WB> This was mentioned because the all-nodes link-scope multicast
>  address FF02::1 can be used to map out all the nodes that are
>  accessible on a link, and thus be used to determine on-link.

Yes. But so?

>  However, that is a different definition of on-link than RFC 4861
>  uses.  It may be applicable to MANET and other groups at IETF.

I don't think it is wise for us to get involved with things that MAY
be applicable to something else that is not yet defined. Since we are
not preventing them from doing something, that is good enough.  IMO,
mentioning this sort of thing just adds confusion and doesn't help us
get closure on this document.

>  Therefore, for the sake of completeness on the topic of on-link
>  determination, we chose to describe it here so that future IETF'ers
>  who will expand Neighbor Discovery to include MANET may use it as
>  reference.  However, upon another read of the text, it's clear that
>  any reception of a link-local packet will yield the same definition
>  - so we can drop the word "multicast" from this bullet."

I'd prefer the entire bullet be removed. It adds nothing to the real
purpose of this document (IMO), which is clarifying the ND spec.

> "WB> Routers decrement the Hop Limit field.  Therefore, there is a
>   Hop Limit (255) that exists that can be used to indicate that
>   packet has not crossed a router.  Note, however, that ND Proxy
>   explicitly keeps the Hop Limit the same, so this definition
>   (especially in the presence of networks that use ND Proxy) yields
>   a different notion of on-link than RFC 4861 and a different notion
>   of on-link than reception of link-scoped packets.

Can you point to an RFC that supports the above? I didn't know proxies
take liberties with the TTL field. And if they do, I suspect things
will not work properly.

> Also, this fact has been mentioned by the MANET team - and I expect
> that they can use this notion as they explore what a "link" means in
> the MANET world.  Further, please note that this bullet is in the
> Host Behavior section and is treated as an observation for the
> benefit of those who will modify Neighbor Discovery in the future
> (the MANET/LOWPAN team),"

Let us please not get distracted by what the MANET team may or may not
be thinking.

IMO, this text is a distraction and doesn't help this document. It
would be better/easier to just omit it.

I.e, the fact that were are discussing this text (which doesn't add
any real value that I can see) is presumably one reason why this
document is still not done... :-(

Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 6 May 2009 15:17:09 -0400

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Wednesday, May 06, 2009 2:58 PM
To: Hemant Singh (shemant)
Cc: JINMEI Tatuya / 神明達哉; Wes Beebee (wbeebee); [email-masked]; [email-masked]
Subject: Re: comments on draft-ietf-6man-ipv6-subnet-model-03

>take liberties with the TTL field. And if they do, I suspect things

See the ND Proxy RFC of RFC 4389 and section 4.1.  Also, an IPv6 router is one IPv6 node that is expected to support ND Proxy. I don’t disagree with anything in the ND Proxy RFC.   So why should we not keep this bullet in our document?

Hemant

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Wed, 6 May 2009 15:19:14 -0400

See comments in-line below: 

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Wednesday, May 06, 2009 1:28 PM
To: JINMEI Tatuya / 神明達哉
Cc: Hemant Singh (shemant); Wes Beebee (wbeebee); [email-masked]; [email-masked]
Subject: Re: comments on draft-ietf-6man-ipv6-subnet-model-03

>       Neighbor Cache as defined in Section 8.1 of [RFC4861].

The core issue is not whether the host realizes that the Redirect is signalling an address is off-link (which obviously can't be done), but rather whether a router could be designed with a specially-crafted Redirect that will cause the host to behave as if the destination is off-link (which is an even stronger case).  The answer is that you CAN craft a Redirect in such a way, by simply including the router as the next-hop (instead of the neighbor host which the node had as a next-hop).  However, hosts will drop such a packet and not update their tables.  The reason for the drop is that "a Redirect message is silently discarded if it does not have an IP source address that is the same as the current first-hop router for the specified ICMP Destination Address".

- Wes

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 6 May 2009 15:23:31 -0400

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Wednesday, May 06, 2009 1:28 PM
To: JINMEI Tatuya / 神明達哉
Cc: Hemant Singh (shemant); Wes Beebee (wbeebee); [email-masked]; [email-masked]
Subject: Re: comments on draft-ietf-6man-ipv6-subnet-model-03

>I must be missing something. One only runs ND on an address when sending a packet to an address, and the Conceptual Sending Algorithm indicates the address is on-link. Right?

Not quite.  For Jinmei's example, Conceptual Sending Algorithm will not indicate that P::Y is on-link because the Prefix List of X does not include P::Y.  Then, given the statement in our document that says an address resolution can only be performed on addresses that are on-link, X cannot send the address resolution NS out.  Remember the private email thread we went through where I said the Conceptual Sending Algorithm doesn’t really apply to ND control messages - this Algorithm is really for data packets.  Your emails today have said repeatedly to just send the NS address resolution out.  I hope you see the controversy now?

Hemant

---

From: Thomas Narten <[email-masked]>
Date: Wed, 06 May 2009 15:49:02 -0400

> See the ND Proxy RFC of RFC 4389 and section 4.1.  Also, an IPv6
>  router is one IPv6 node that is expected to support ND Proxy. I
>  don't disagree with anything in the ND Proxy RFC.  So why should we
>  not keep this bullet in our document?

OK. I thought you were using a different notion of proxy (i.e., as is
used by MIPv6, where the P bit is not used).

Getting back to the original issue raised w.r.t. this point:

draft-ietf-6man-ipv6-subnet-model-03.txt currently says:

I do not see what value this text adds to the document and think it
would be simplest to just remove it. Even now understanding what you
meant by "proxy" in your followup response above, my opinion remains
that the text in the document is not necessary or helpful.

Thanks,
Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 6 May 2009 15:56:06 -0400

Thomas,

Fine.  We will remove bullets 6 and 7 from section 2 of the document.  To summarize progress thus far, we have also decided to keep the paragraph on Redirect bullet as is and not take new text.  The only pending issue left now (after yours and Jinmei's comments) is what do we do with the statement in our draft that says to not issue an address resolution for an IPv6 address that is not on-link - see my recent email on this one.

Thanks,

Hemant 

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Wednesday, May 06, 2009 3:49 PM
To: Hemant Singh (shemant)
Cc: JINMEI Tatuya / 神明達哉; Wes Beebee (wbeebee); [email-masked]; [email-masked]
Subject: Re: comments on draft-ietf-6man-ipv6-subnet-model-03

"Hemant Singh (shemant)" <[email-masked]> writes:

> Cc: JINMEI Tatuya / 逾樊・驕泌悼; Wes Beebee (wbeebee); [email-masked]; [email-masked]

Thanks,
Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 7 May 2009 12:01:55 -0400

Folks,

The issue related to "the statement in our draft that says to not issue an address resolution for an IPv6 address that is not on-link" has been addressed by the following new and amended text in Intro section of our 04 draft that has been posted today.  I also fixed a few typos in the new text below but the typos do exist in the -04 version.

OLD:

   A host only performs address resolution for IPv6 addresses that are
   on-link.  Packets to any other address are sent to a default router.
   If there is no default router, then the node should send an ICMPv6
   Destination Unreachable indication as specified in [RFC4861] - more
   details are provided in the Host Behavior and Rules section.  (Note
   that [RFC4861] changed the behavior when the Default Router List is
   empty.  The behavior in the old version of Neighbor Discovery
   [RFC2461] was different when there were no default routers.)

NEW:

   IPv6 packets sent using the Conceptual Sending Algorithm as described
   in [RFC4861] only trigger address resolution for IPv6 addresses that
   are on-link.  Note that transmission of ND messages is not governed
   by the Conceptual Sending Algorithm.  Packets to any other address
   are sent to a default router.  If there is no default router, then
   the node should send an ICMPv6 Destination Unreachable indication as
   specified in [RFC4861] - more details are provided in the Host
   Behavior and Rules section.  (Note that [RFC4861] changed the
   behavior when the Default Router List is empty.  The behavior in the
   old version of Neighbor Discovery [RFC2461] was different when there
   were no default routers.)  Note that ND is scoped to a single link.
   All Neighbor Solicitation responses are assumed to be sent out the
   same interface on which the corresponding query was received.

Thanks,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: Wednesday, May 06, 2009 3:56 PM
To: Thomas Narten
Cc: [email-masked]; [email-masked]
Subject: RE: comments on draft-ietf-6man-ipv6-subnet-model-03

Thomas,

Thanks,

Hemant 

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Wednesday, May 06, 2009 3:49 PM
To: Hemant Singh (shemant)
Cc: JINMEI Tatuya / 神明達哉; Wes Beebee (wbeebee); [email-masked]; [email-masked]
Subject: Re: comments on draft-ietf-6man-ipv6-subnet-model-03

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 07 May 2009 11:53:15 -0700

At Wed, 06 May 2009 13:28:03 -0400,

> node B as on-link (and it is in fact).

I believe I understand your position.  My baseline point is that such
failure modes should be extremely rare "in practice" (looks like we
have different definitions of this term).  In fact, there's an
implementation that already fails in this situation as I pointed out
in an off-list discussion.  (I don't think it's confidential so I
copied the relevant part below. note: BSD used to work this way
because it considered a neighbor an on-link node, so I'm talking about
a different implementation than BSD here).  Yet, as far as I know,
there has been no problem report about this failure for years.  This
strongly indicates no one has ever needed such a case.

One could still argue that we "may" need it "in the future" (and
that's probably why you said "will happen").  If we could implement it
with no or less cost, I might agree.  But I know this would make the
implementation I'm involved with (that is, BSD) too complicated.
Besides, they already introduced the tighter filtering of incoming NS
for the security reason that triggered this discussion.  I'm also
pretty sure that they now reject the complicated patch with canceling
the filtering simply because it's in the specification and there may
be of use in the future.

I can imagine a counter argument from a protocol architect that the
protocol definition shouldn't be affected for the sake of a particular
implementation's convenience.  As a general rule, I see the point.
But at the same time, since I believe won't lose anything "in
practice" even if we make the "failure mode" keep failing, and in that
case keeping some implementation simple can be justified in defining a
protocol.  If, for example, we really encounter a realistic
operational requirement that needs this behavior, we may then be able
to consider extending the rule again.

I hope I've clarified my point sufficiently.  You may still not agree
with me, and, in that case, I'm afraid we cannot resolve it through
further technical discussions.  If we can make rough consensus from
any follow-up discussions, that would be great; if not, maybe we
should hum or vote to move forward.

p.s. I'll be mostly offline until May 20 for vacation (officially I'm
already off).  I'm sorry for not being able to be so responsive.  I
hope we can make progress without me (hopefully toward the way I
wish:-).

---
JINMEI, Tatuya

> > The difficult part is how the responding node out the solicited NA (to
> > P2::B in the above scenario).  Since the NA is also a normal IPv6
> > packet originated from the node, one reasonable assumption would be
> > that it follows the Conceptual Sending Algorithm as described in
> > section 5.2 of RFC4861.
>
> It was never intended that NS/NA (or RA/RS messages) go through the
> normal IP processing rules. That ways lies madness. The spec may not
> actually say that, but I don't see how you can reasonably conclude
> that is a reasonable way to proceed.
>
> And, given that nobody (AFAIK) has implemented things this way, I'm
> surprised that we are having this conversation...

At least BSD does this.  Of course, it doesn't naively follow the
conceptual sending algorithm: it ensures the outgoing interface be the
same as the receiving interface of the corresponding NS, but it
implements this restriction by creating a host route (a "destination
cache" according to ND-ish terminology) and uses the general IPv6
output routine that follows the conceptual sending algorithm.

Solaris also seems (according to the source code) to call a general
IPv6 output routine to send ND packets (specifically, NA in response
to NS).  It uses a more explicit approach to specify the outgoing
interface.  However, the Solaris box I used to test couldn't actually
send out the NA to P2::B in the above scenario, even though it could
create a neighbor cache for P2::B as specified in the RFC.

The case of DHCP-PD delegating router I mentioned in the dhc list:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg09092.html is
another example of how the implementation of this part could be
tricky.  Note that this was about an actual product, rather than just
a logical case analysis with an imaginary implementation (I don't know
the origin of the implementation, though, so it might just be BSD or
Solaris-based).

All these cases seem to me to indicate that the protocol author's
intent was not so obvious for implementors and that implementing it as
intended by the protocol author may not be that trivial.  That's my
point in this discussion.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 8 May 2009 16:02:20 -0400

Jinmei and 6man -

Please note that we have taken care of all but one of Jinmei's comments and issues found in the -03 version of our document and our corrections are in the -04 posted yesterday (please note Bert's change is not included in the -04 version, but the new paragraph was sent to 6man).  The one issue we haven't taken care of raised by Jinmei is that he would like a change made to the ND protocol, alluded to below.  In summary, Jinmei wants the receiver of an NS message to check if the source of the NS is on-link to the receiver, and if it is not, then the receiver MUST drop the NS.

We agree with Thomas Narten and feel that this is a big change to the ND protocol.  This change also makes ND less robust and can lead to loss of network connectivity.  Unfortunately, Jinmei is on vacation until after the Last Call expires.  Can we discuss this issue with others in the working group to help determine the consensus of the working group?

Thanks,

Wes

-----Original Message-----
From: JINMEI Tatuya / 神明達哉 [mailto:[email-masked]] 
Sent: Thursday, May 07, 2009 2:53 PM
To: Thomas Narten
Cc: Hemant Singh (shemant); Wes Beebee (wbeebee); [email-masked]; [email-masked]
Subject: Re: comments on draft-ietf-6man-ipv6-subnet-model-03

At Wed, 06 May 2009 13:28:03 -0400,
Thomas Narten <[email-masked]> wrote:

> it would make ND less robust than it is today or needs to be. 
> Specifically, such a rule would result in Node A not being able to 

I believe I understand your position.  My baseline point is that such failure modes should be extremely rare "in practice" (looks like we have different definitions of this term).  In fact, there's an implementation that already fails in this situation as I pointed out in an off-list discussion.  (I don't think it's confidential so I copied the relevant part below. note: BSD used to work this way because it considered a neighbor an on-link node, so I'm talking about a different implementation than BSD here).  Yet, as far as I know, there has been no problem report about this failure for years.  This strongly indicates no one has ever needed such a case.

One could still argue that we "may" need it "in the future" (and that's probably why you said "will happen").  If we could implement it with no or less cost, I might agree.  But I know this would make the implementation I'm involved with (that is, BSD) too complicated.
Besides, they already introduced the tighter filtering of incoming NS for the security reason that triggered this discussion.  I'm also pretty sure that they now reject the complicated patch with canceling the filtering simply because it's in the specification and there may be of use in the future.

I can imagine a counter argument from a protocol architect that the protocol definition shouldn't be affected for the sake of a particular implementation's convenience.  As a general rule, I see the point.
But at the same time, since I believe won't lose anything "in practice" even if we make the "failure mode" keep failing, and in that case keeping some implementation simple can be justified in defining a protocol.  If, for example, we really encounter a realistic operational requirement that needs this behavior, we may then be able to consider extending the rule again.

I hope I've clarified my point sufficiently.  You may still not agree with me, and, in that case, I'm afraid we cannot resolve it through further technical discussions.  If we can make rough consensus from any follow-up discussions, that would be great; if not, maybe we should hum or vote to move forward.

p.s. I'll be mostly offline until May 20 for vacation (officially I'm already off).  I'm sorry for not being able to be so responsive.  I hope we can make progress without me (hopefully toward the way I wish:-).

---
JINMEI, Tatuya

> > The difficult part is how the responding node out the solicited NA 
> > (to P2::B in the above scenario).  Since the NA is also a normal 
> > IPv6 packet originated from the node, one reasonable assumption 
> > would be that it follows the Conceptual Sending Algorithm as 
> > described in section 5.2 of RFC4861.
>

At least BSD does this.  Of course, it doesn't naively follow the conceptual sending algorithm: it ensures the outgoing interface be the same as the receiving interface of the corresponding NS, but it implements this restriction by creating a host route (a "destination cache" according to ND-ish terminology) and uses the general IPv6 output routine that follows the conceptual sending algorithm.

Solaris also seems (according to the source code) to call a general
IPv6 output routine to send ND packets (specifically, NA in response to NS).  It uses a more explicit approach to specify the outgoing interface.  However, the Solaris box I used to test couldn't actually send out the NA to P2::B in the above scenario, even though it could create a neighbor cache for P2::B as specified in the RFC.

The case of DHCP-PD delegating router I mentioned in the dhc list:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg09092.html is another example of how the implementation of this part could be tricky.  Note that this was about an actual product, rather than just a logical case analysis with an imaginary implementation (I don't know the origin of the implementation, though, so it might just be BSD or Solaris-based).

All these cases seem to me to indicate that the protocol author's intent was not so obvious for implementors and that implementing it as intended by the protocol author may not be that trivial.  That's my point in this discussion.