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

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 1 Jul 2008 10:44:17 -0400

David,

Please see in line below between "<hs>" and "</hs>".

-----Original Message-----
From: MILES DAVID [mailto:[email-masked]] 
Sent: Monday, June 30, 2008 8:24 PM
To: Hemant Singh (shemant); Wes Beebee (wbeebee); [email-masked]
Cc: Thomas Narten; [email-masked]
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Thanks Hemant and Wes,

To your question on examples - this came about as a result of customer
interpretation of RFC 4861 (and a specific test case).

<hs> May we know more about this customer test cases? Is your host to
host example also something that your customer is testing? If yes, what
OS are the hosts running and why are hosts not behaving correctly for
basic source address selection? Further if your customer is testing
router to router ND, what router is being used and what is firmware
version on the router? You see, in IETF such details need to be open to
nail down any discussion. Anyhow, for the router to router example you
gave, Thomas Narten and Erik have already closed that issue saying no
harm is caused because the bogus ND-cache entry is not used. We closed
the host to host example in our earlier email saying the forwarding
table on the host will take precedence over ND-cache - just like the
router to router ND example.
</hs>

 The RFC literally says one should populate Neighbour Cache when you
receive a NS regardless of whether that address is in the Prefix List
and any NA/ND received is on-link. This process in RFC 4861 does not
describe how on-link determination is affected so I hoped we can have
this discussion to conclude whether the text should remain or whether we
need to clarify on-link determination. The examples you have used (no
router with
manual/DHCPv6 assigned addresses) are much better.

My query relates to text in both RFC4861 and your draft, where we say
that any ND received means the address is considered on-link. In your
draft you explicitly state (in point 5) that if there are no Default
Routers, and no other information indicating on-link prefix (including
the mere presence of an address) then (sub-point 2): "The host MUST NOT
perform address resolution for non-link-local addresses".
This would seem to create a stalemate situation. I.e., for any received
ND a host will consider that address on-link (bullet point in question
in RFC4861), but you MUST NOT perform address resolution unless a
destination address is on-link (your draft section 5.2) and so cannot
populate other hosts with your addresses by sending NS.

<hs> Not quite. Bullet 5 from section 2 of our draft is derived from
RFC4943. Please read section 4 of RFC4943 that said on-link assumption
is harmful. Our bullet is totally correct to say, once it has been
determined that an address or prefix is not on-link, then of course, the
address or prefix is off-link. If an address or prefix is off-link,
then, of course, an interface cannot issue an NS to resolve any
non-link-local destination. There is no stalemate because only if no
on-link determination could be made on an address or prefix, does the
node goes into recommended procedure of RFC4943 to send an ICMP
Destination Unreachable. Of course, if an on-link determination has been
made because if an NS was received at the interface in a router-less
network, and prefix length is configured on the interface's configured
IPv6 address, the recommended operation of RFC4943 will not take place. 
</hs>

 NA are not periodically sent and a receiving host should discard them
if the target does not match a valid interface (RFC 4861 7.2.5).

Per your email, the intent is clearly for the receipt of a ND to update
on-link determination (this ::/128 is now on-link). We must also ensure
we will send ND for this on-link address to update other hosts.

As want the reception of a ND to indicate that address (the
target/source of a NA, and the source of a NS) is on-link we need some
clarifying text that would describe:
- How on-link determination is enhanced with information from ND
messages received
- That we shouldn't discard NA with a target that isn't in the receiving
host's Neighbour Cache - we need to somehow update on-link determination
with information from the NA
- Whether we update Prefix List with ::/128 from the received ND
messages; consult Neighbour Cache for on-link determination; create an
entry in the Destination Cache, etc
- Determine how long an address will be considered on-link for. What
lifetime will we associate with this learnt on-link address? Until
interface reset/reinitialise or receipt of a PIO? What if a default
router becomes active - should we still treat this ::/128 (from a
received ND) on-link?
- How a hostA will send NA/ND to other hosts so they may determine
hostA's address is on-link

<hs>I, Wes, Erik, and Thomas have already made is clear that routing
table on a router or data forwarding table on a host takes precedence
over any ND-cache entry. Further, any change in drafts or RFC's are made
if any severe problem is found for tens of millions of nodes. We haven't
see such a problem in your router-less host example. It makes sense to
consider your alternatives below. 
</hs>

The other alternatives are to:
- Require a prefix-len be specified when manually configuring an address
(ie, adopt SLAAC rules)

<hs> Our draft already covers such a thought. Please see bullet 2 of
section 2 in our draft. One sentence in the bullet says:
[Note that this requirement for manually configured addresses is not
explicitly mentioned in [RFC4861].]. We highlighted manual configuration
in our draft. After that, it is clear as daylight that on-link
determination for a prefix cannot be made unless a prefix length is also
available with the prefix in manual configuration. I think bullet 2
should suffice for this alternative suggestion by you.
</hs>

- Add prefix-len to DHCPv6 IA_NA/TA Options to support environments
without routers (only used when there is no RA received) 

<hs> Please read emails from me in 6man archives where I have clearly
said, I will never agree to adding prefix len as a DHCPv6 option. My
reasons are clear in the emails archived. When I get the time, I can
forward some emails privately to you. But, please let's not gate this
draft waiting for those emails.

I hope we can get closure with this email.
</hs>

Thanks.

Hemant

- Mandate the requirement for RA to support any IPv6 address other than
link-local

Best Regards,

-David Miles

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: Tuesday, 1 July 2008 12:37 AM
To: MILES DAVID; Wes Beebee (wbeebee); Wojciech Dec (wdec); Brian
Haberman; [email-masked]
Cc: Bob Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

David,

We will explain where we think RFC4861 came from with the 4th bullet in
on-link definition in Terminology section of RFC4861. We will explain
why that bullet is needed and why the bullet does not change. Further,
we don't understand where you are going with these contrived examples?
It's a stretch already being in a router-less network and contriving
examples that clearly have source-address selection problems. In the
routerA to routerB contrived example, the example included routes
between A and B. We have said routing table takes precedence over ND
cache in that example. For the host to host case below, since IPv6
addresses have been configured on the hosts with a prefix length, each
host has an entry in data forwarding table for the prefix derived from
host IPv6 address configuration. IPv6 data forwarding tables on the host
will take precedence in the same way as in your router example.

Anyhow, here is the justification for the 4th bullet in RFC 4861 which
is what statements in our draft derive from.

In a router-less network, a node's network interface may be configured
using manual configuration or DHCPv6. Note DHCPv6 does not dole out
prefix length without which, just given an IPv6 address from DHCPv6, a
DHCPv6 client cannot make an on-link determination for any prefix.
Likewise, manual configuration may not configure a prefix length when an
IPv6 address is configured on the interface - in this case, the node
still does not have any means to determine what prefix is on-link.  Thus
far, any host in this network has not been able to determine if any
prefix is on-link. Only if the host is able to determine any prefix is
on-link, can the host in such a network send data. There in comes the
rule in 4th bullet from the definition of on-link from RFC4861 that
applies to this network

- any Neighbor Discovery message is received from the address.

Hemant & Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
MILES DAVID
Sent: Thursday, June 26, 2008 8:57 PM
To: Wes Beebee (wbeebee); Wojciech Dec (wdec); Brian Haberman;
[email-masked]
Cc: Bob Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Wes & Hemant,

Can we walk through the situation of hosts without routers where you
suggest a possible issue?

HostA ----(link)---- HostB

HostA:
2002:db8:100::1234/64
2002:db8:200::1234/64

HostB:
2002:db8:100::9999/64

Are we suggesting HostA may src from 2002:db8:200::1234 to
2002:db8:100::9999, ie, we are forgoing source-address selection and are
overriding this behaviour?
Assuming that is the case, and assuming HostB did in fact populate a
Neighbour Cache entry with 2002:db8:200::1234 - STALE, I cannot see how
this would affect HostB's next-hop/on-link determination.

According to the current text in RFC4861 HostB would perform the
following on the first packet to send to 2002:db8:200::1234:
1) Check destination cache (empty, never seen this destination before)
2) Check Prefix List for on-link determination (off-link) -
2002:db8:200::1234 is not in the Prefix List
3) If off-link, select a router from Default Router List and determine
next-hop IP (no default routers) --end in our example as there are no
routers--
4) Consult Neighbour Cache for link-layer address of next-hop, invoke
Address Resolution if needed
5) Cache result in destination cache

I understand Neighbour Cache is not consulted for next-hop/on-link
determination, and Destination Cache is updated with the result of the
Prefix-List lookup (next-hop determination). So while there is a STALE
entry in the Neighbour Cache, it is never queried. Similar to the case
of a router, I think we would need to update a host's equivalent (the
Prefix List) to affect forwarding.

It would be good to better understand the scenario you are seeing
between host and host. 

Best Regards,

-David

-----Original Message-----
From: Wes Beebee (wbeebee) [mailto:[email-masked]]
Sent: Friday, 27 June 2008 12:29 AM
To: Wojciech Dec (wdec); Brian Haberman; [email-masked]
Cc: MILES DAVID; Bob Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

This rule derives directly from the Terminology section of RFC 4861
(definition of on-link).

Note that the presence of a bogus entry causes no harm (the routing
table takes precedence over the ND cache in this case).

However, the removal of the rule DOES cause harm in the case of
communication without routers.

Therefore, we currently see no reason to change the text.

- Wes & Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wojciech Dec (wdec)
Sent: Thursday, June 26, 2008 10:05 AM
To: Brian Haberman; [email-masked]
Cc: MILES DAVID; Bob Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Based on a recent thread
(http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00896.html) the
following paragraph from the draft appears to warrant some more thought
if not outright a revision

"   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."

Using unconditionally the source address of a neighbour solicitation or
NA to determine on-link would indeed appear to be undesirable, unless
the intent is allow some direct host-host cross subnet/prefix
communication without a router involved at any stage (this is not a good
idea IMO). A constraint could be introduced such as: A host only learns
on-link addresses from the source of NS and NA messages iff it already
has an on-link prefix that would cover that address. Learning from
Redirect messages would continue to be allowed.

My 2c.
-Woj.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Brian Haberman
> Sent: 26 June 2008 14:17
> To: [email-masked]
> Cc: Bob Hinden
> Subject: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
> 
> All,
>       This message starts a 3-week 6MAN Working Group Last Call on
> advancing:
> 
>       Title     : IPv6 Subnet Model: the Relationship between
>                   Links and Subnet Prefixes
>       Author(s) : H. Singh, et al.
>       Filename  : draft-ietf-6man-ipv6-subnet-model-00.txt
>       Pages     : 8
>       Date      : 2008-05-08
> 
> as a Proposed Standard.  Substantive comments and statements of 
> support for advancing this document should be directed to the mailing 
> list.
> Editorial suggestions can be sent to the document editor.  
> This last call will end on July 10, 2008.
> 
> Regards,
> Brian & Bob
> 6MAN co-chairs
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "MILES DAVID" <[email-masked]>
Date: Thu, 3 Jul 2008 08:22:55 +0800

Hemant,

Thanks for your patience.

Given we are now very clear that a receiver should drop any ND message
from a source that it is not in its prefix list, might I suggest the
paragraph in question be amended to say:
In addition to the Prefix List, individual addresses are on-link if
   they are the target of a Redirect Message indicating on-link.

Removing the text: 
or the
   message.

The clarification would be a step in the right direction.

My 2c, and yes - this is now closed. 

-David

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: Wednesday, 2 July 2008 12:44 AM
To: MILES DAVID; Wes Beebee (wbeebee); [email-masked]
Cc: Thomas Narten; [email-masked]
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

David,

-----Original Message-----
From: MILES DAVID [mailto:[email-masked]] 
Sent: Monday, June 30, 2008 8:24 PM
To: Hemant Singh (shemant); Wes Beebee (wbeebee); [email-masked]
Cc: Thomas Narten; [email-masked]
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Thanks Hemant and Wes,

Thanks.

Hemant

Best Regards,

-David Miles

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: Tuesday, 1 July 2008 12:37 AM
To: MILES DAVID; Wes Beebee (wbeebee); Wojciech Dec (wdec); Brian
Haberman; [email-masked]
Cc: Bob Hinden

David,

Hemant & Wes

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

Wes & Hemant,

HostA:
2002:db8:100::1234/64
2002:db8:200::1234/64

HostB:
2002:db8:100::9999/64

Best Regards,

-David

-----Original Message-----
From: Wes Beebee (wbeebee) [mailto:[email-masked]]
Sent: Friday, 27 June 2008 12:29 AM
To: Wojciech Dec (wdec); Brian Haberman; [email-masked]
Cc: MILES DAVID; Bob Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

- Wes & Hemant

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

Based on a recent thread

My 2c.
-Woj.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 2 Jul 2008 20:33:38 -0400

David,

No problem, you're welcome. I will talk with my co-authors in Erik and
Wes and see what we can do. To us it's obvious that ND is a link-local
scoped protocol and of course, if a receiver sees an ND message that is
not present in the receiver's on-link prefixes, the receiver has to drop
the ND message. That is what Erik said too in v6ops on 25th June 2008.
Sorry, at the time I wasn't subscribed to v6ops and saw your thread a
day or two later. Otherwise I would have said the same.

Kind Regards.

Hemant 

-----Original Message-----
From: MILES DAVID [mailto:[email-masked]] 
Sent: Wednesday, July 02, 2008 8:23 PM
To: Hemant Singh (shemant); Wes Beebee (wbeebee); [email-masked]
Cc: Thomas Narten; [email-masked]
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Hemant,

Removing the text: 
or the

-David

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: Wednesday, 2 July 2008 12:44 AM
To: MILES DAVID; Wes Beebee (wbeebee); [email-masked]
Cc: Thomas Narten; [email-masked]
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

David,

-----Original Message-----
From: MILES DAVID [mailto:[email-masked]]
Sent: Monday, June 30, 2008 8:24 PM
To: Hemant Singh (shemant); Wes Beebee (wbeebee); [email-masked]
Cc: Thomas Narten; [email-masked]
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

Thanks Hemant and Wes,

Thanks.

Hemant

Best Regards,

-David Miles

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: Tuesday, 1 July 2008 12:37 AM
To: MILES DAVID; Wes Beebee (wbeebee); Wojciech Dec (wdec); Brian
Haberman; [email-masked]
Cc: Bob Hinden

David,

Hemant & Wes

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

Wes & Hemant,

HostA:
2002:db8:100::1234/64
2002:db8:200::1234/64

HostB:
2002:db8:100::9999/64

Best Regards,

-David

-----Original Message-----
From: Wes Beebee (wbeebee) [mailto:[email-masked]]
Sent: Friday, 27 June 2008 12:29 AM
To: Wojciech Dec (wdec); Brian Haberman; [email-masked]
Cc: MILES DAVID; Bob Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

- Wes & Hemant

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

Based on a recent thread

My 2c.
-Woj.

---

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

> from a source that it is not in its prefix list,

No, I would not go that far. There is no harm in responding to an NS
for a target address that is assigned to your interface. Indeed, it is
necessary to make communication work in some situtations. What should
not happen, however, is to use reciept of an ND message as an
indication that the sender of that message is on-link. (i.e.,
overriding or supplementing information learned from other means).

Likewise, receipt of an NA should not be taken as an indication that
the sender of that NA is on-link (i.e, anyone could just send out a
broadcast NA with bogus info in it). One should NOT create a Neighbor
Cache Entry upon receipt of a random (unsolicited) NA. (Luckily, the
spec already says you shouldn't do this, though for different
reasons.)

But if one has issued an NS for a particular address (because one
already believes the target is on-link), receipt of an NA should (of
course) update the neighbor cache for that entry.

> might I suggest the

> The clarification would be a step in the right direction.

IMO, removing that line is the right thing to do.

It is clear to me that bullet four in RFC 4861:

>    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
> 

Is wrong and needs tweaking. We should fix that on the next update of
the ND spec. :-)

That said, we are clearly talking about an edge case situation here
that hasn't come up in practice very often. So the urgency of fixing
this is not terribly great, IMO. But going forward (i.e, in any new
documents), we should do the right thing.

Thomas

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 3 Jul 2008 11:51:25 -0400

Thomas,

BTW, Erik sent this email to v6ops on June 25th, 2006 that the receiver
should drop such an ND Message - it's snipped between quotes below.

"David Miles wrote:

I'd also suggest that in the Message Validation section we include the
checks you mention (is the source of the ND or target of the NA an
on-link prefix per Prefix List) 

If you do that, how would communication work in your example?

The NS would be dropped since its source isn't covered by an on-link
prefix on the receiver, right? 

   Erik"

Anyhow, we already sent an email to Erik suggesting the following
changes to our subnet-model draft. The gist of our changes are indeed to
say that the 4th bullet of on-link definition is not a valid means to
determine on-link. 

For reference, here is the URL to our draft.

http://www.ietf.org/internet-drafts/draft-ietf-6man-ipv6-subnet-model-00
.txt

Here are the two changes we have proposed to our draft.

1. In Introduction section, here is new text:

[In addition to the Prefix List, individual addresses are on-link if
they are the target of a Redirect Message indicating on-link.]

2. In section 2, we reworded bullet 2 as follows:

                  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 the
definition of on-link in the 
                  Terminology section of [RFC4861].  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]. 

Do the changes look OK to you and everyone else?

Thanks.

Hemant 

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Thursday, July 03, 2008 11:34 AM
To: MILES DAVID
Cc: Hemant Singh (shemant); Wes Beebee (wbeebee); [email-masked];
[email-masked]
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt

> from a source that it is not in its prefix list,

No, I would not go that far. There is no harm in responding to an NS for
a target address that is assigned to your interface. Indeed, it is
necessary to make communication work in some situtations. What should
not happen, however, is to use reciept of an ND message as an indication
that the sender of that message is on-link. (i.e., overriding or
supplementing information learned from other means).

Likewise, receipt of an NA should not be taken as an indication that the
sender of that NA is on-link (i.e, anyone could just send out a
broadcast NA with bogus info in it). One should NOT create a Neighbor
Cache Entry upon receipt of a random (unsolicited) NA. (Luckily, the
spec already says you shouldn't do this, though for different
reasons.)

That said, we are clearly talking about an edge case situation here that
hasn't come up in practice very often. So the urgency of fixing this is
not terribly great, IMO. But going forward (i.e, in any new documents),
we should do the right thing.

Thomas

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 14 Jul 2008 02:25:41 -0700

> from a source that it is not in its prefix list,

Sorry for not catching this earlier, but as I pointed out in an earlier 
message, dropping such ND messages would cause failure to communicate in 
some cases.

Hence the proposed cure is worse than the decease IMHO.

FWIW what I said in v6ops is included below. I think "problematic for 
sure" meant "broken, don't do that".

    Erik

-------- Original Message --------
Subject: Re: Neighbor Discovery and on-link determination
Date: Wed, 25 Jun 2008 06:25:38 -0700
From: Erik Nordmark <[email-masked]>
To: David Miles <[email-masked]>
CC: Thomas Narten <[email-masked]>, IETF V6OPS WG <[email-masked]>
References: <[email-masked]> 
<[email-masked]> 
<[email-masked]> 
<[email-masked]> 
<[email-masked]>

David Miles wrote:
 >
 > Hi Erik,
 >
 > I'll put both answers into one email:
 >
 >
 > If routerA sent a ND to routerB and the source address of the ND if
 > off-link, populating the Neighbour Cache will not achieve any real
 > functionality. Yes, I'd propose it is ignored by the router. Possibly we
 > could trigger a unsolicited Neighbour Advertisement from RouterB?
 > I cannot see any impact on redirect or proxy service functionality and I
 > really see this as a misconfiguration.

The message validation rules that you referred to are cases when the
packet would be ignored (and that would be problematic for sure.)

It makes sense to look carefully at the effect of "do not create a
neighbor cache entry for the sender if sender is not in one of the
on-link prefixes".

 > With respect to your other email and my security concerns:  if  the
 > receipt of a ND or NA on any interface, irrespective of prefix list,
 > were able to both populate the Neighbour Cache and update/affect the
 > forwarding behaviour then I would be worried. Seeing you have both
 > clarified this was not the intent I do not have an issue, but it does
 > seem of little benefit to populate a Neighbour Cache entry if it is
 > never consulted.
 >
 > I know the scenario is contrived however it was brought to my attention
 > from another source, so the clarifications are appreciated.

OK

    Erik

  might I suggest the

---

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

> Is wrong and needs tweaking. We should fix that on the next update of

I agree that bullet four doesn't seem useful.
But I think the same thing applies to the third bullet above; I know of 
no case where it is necessary or useful, and I think it is a potential 
security issue if implemented on multi-interfaced nodes, since the 
receipt of an NA on interface B could conflict with the fact that the 
while prefix is on-link on interface A.

Popping up a level, we set out to clarify the subnet model in this 
draft. Until recently I considered David's on-link issues to be separate 
from the subnet model. But after catching up on this whole thread it 
seems the two issues are closely related.

Hence my question for the WG. Should we expand the scope of 
draft-ietf-6man-ipv6-subnet-model to also clarify/change the on-link 
handling in RFC 4861?

    Erik