Subject: Re: RFC 2461- issue list: Prefixes with L=0

From: "JinHyeock Choi" <[email-masked]>
Date: Mon, 3 Nov 2003 23:06:01 +0900

Dear Hesham

Something about prefixes with L=0 are confusing to me. Kindly see
below.  

1. The prefixes with L bit off. 
- The meaning/ purpose of prefixes with L=0 is not exactly clear 
   to me. What's the use of non-on-link prefixes for a node? 

2. The prefixes assigned to more than one links.
- According to RFC 2461, it's legitimate to assign a prefix (with L=0) 
   to two separate links. But it's not clear to me on what condition 
   can we do this.   

 I wish we clarify the above. The prefixes with L=0 makes DNA work 
complicated. Though they are troublesome, I am afriad that, in wireless
environment, we can't avoid them.

Best regards

JinHyeock

 DÅ ûúÂŠäŠx ®‹©™¨¥Šx%ŠËb¦þ¢z×è®š)â²ÚÚ¶+ÞEê®zËl†Ûi³ÿðÃ
bz×è®æj)fjåŠËbú?Š›ú

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 04 Nov 2003 09:07:48 +0900

>>>>> On Fri, 31 Oct 2003 12:52:14 +1100, 
>>>>> Greg Daley <[email-masked]> said:

> The difficulty comes when an RS comes from a global
> source address which is not directly connected to
> a router.

> Based on RS processing rules, the host which sent
> the RS is within a hop of the router, but has asked for
> an RA from an address which doesn't exist locally.

It is not very clear what "an address which doesn't exist locally"
means.  I guess you probably mean, e.g., an address that belongs to a
prefix that the receiving router does not configure as on-link.

RFC2461 clearly (IMO) says that such an address must be regarded as
on-link:

   on-link     - an address that is assigned to an interface on a
                 specified link.  A node considers an address to be on-
                 link if:
   (snip)
                    - any Neighbor Discovery message is received from
                      the address.
(Section 2.1 of RFC2461)

Note that in this case a neighbor discovery message (router
solicitation) is received from the address.

> Does the router reply to a message which has a source
> address not believed to be on this link?

So, again, it is not clear what "a source address not believed to be on
this link" means, but if the question is, e.g., 

  Does the router reply to a message which has a source
  address that belongs to a prefix that the receiving router does not
  configure as on-link?

then the answer is yes.

> Does it only reply with a multicast destination?

No, a unicasted response is also valid.

> What do current implementations do in this case?

This doesn't help your question here, but FWIW, the KAME/BSD
implementation only supports for multicast router advertisement.
So, the implementation always replies with a multicast destination,
whether the source of the solicitation is link-local or global.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

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

---

From: Greg Daley <[email-masked]>
Date: Tue, 04 Nov 2003 12:18:10 +1100

Dear Jinmei-san,

> solicitation) is received from the address.

Indeed.

This is quite possibly incorrect behaviour though, since
wireless nodes may have mistaken ideas as to where they
are connected, and send Router Solicitations (quite unaware)
from global addresses which are _not_ on-link.

It is very likely in the case that a node has changed its
link-layer connection, but it has not received an RA,
that it has invalid configuration on the link.

In this case, should the router put entries into its
ND cache for addresses from global prefixes associated
with another subnet?

I'm not conviced (yet) that it should (even if it's allowed
to by RFC-2461).

>   address that belongs to a prefix that the receiving router does not

I can understand if the router responds with a multicast
(since even :: addresses are capable of receiving a
multicast response). I'm more concerned about the creation
of incorrect state for the router.

For example, invalid NC state could be used to create local
routing between addresses on seemingly unconnected subnets,
without going through the router controlling the foreign prefix.

I've not got any dire predictions as to why this would be a
bad thing, but it seems unnecessary (since we have LL) and
incorrect (since NC's will have entries which don't
reflect the routing architecture).

> No, a unicasted response is also valid.

Which means that we accept any prefix from any host as part
of a valid address, to put in our neighbor caches.

So all a node has to do to get bidirectional communication
with hosts on a link is to (if it knows their address, as
with the router): send them an NS or RS with SLLAO with an
arbitrary source address (or even send RS without SLLAO,
and respond to the router's NS).

This will place an NC on the peer.

No routing involved, just neighbor discovery.

I'm just wondering if this was the intended functionality?

> whether the source of the solicitation is link-local or global.

That's helpful to know though.

radvd primarily works on multicast advertisement,
but I'll have to check the source to see how it works for
unicast too.

Thanks for your help.

Greg