Subject: [6lowpan] NS source address in nd-09

From: "Reddy, Joseph" <[email-masked]>
Date: Thu, 27 May 2010 23:28:07 -0500

Hi ND authors,

I have a question on the choice of source address for the NS packets

When a new address is to be configured, the draft requires the host to send NS with with the IPv6 source address set to this address and to also include ( must ) the SLLA option

Does this not cause a violation of the address scoping rules ( since the destination address is a link local address derived from the RA while the source is a global, assuming we want to register a global address ) ?

Is there a reason why the unspecified address is not used for the source ( and include the address in the ARO option ) like in classic ND ? If this is because you want to include the SLLA option, note that this is not really necessary since the link layer source address can be deduced by the router from the L2 headers

Also, if a host wants to register with multiple routers, it seems that each of the routers will end up doing the multihop DaD on the address. This will waste bandwidth ( as well as reduce battery life of host since the process will be much longer ). Instead, it will be useful to allow the host to differentiate between the intial address registration ( when DaD is needed ) and subsequent ones. One way to do this would be to use the unspecified source address during initial registration followed by the actual address for subsequent ones.

-Regards, Joseph

------------------------------

Message: 2
Date: Wed, 26 May 2010 15:21:50 -0700
From: Tetsuya Murakami <[email-masked]>
Subject: [6lowpan] SLLA option in NS
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

Hi All,

According to the current 6lowpan-nd draft, I have one question.

The draft mentioned NS must include SLLA option in order to inform the link-layer address of the host. However when the router receives RS message from the host, the router responds RA to the host. At that time, the router needs to know the link-layer address of the host in order to send out RA to the host. So, I think SLLA option of the host must be included in RS instead of NS.

According to the current ND draft, after receiving RS message, the router sends NS message in order to solve the link layer address of the host by using solicited node multicast address. In order to eliminate the multicast packet as much as possible, I recommend to include SLLA option in RS instead of NS.

Thanks,
Tetsuya Murakami

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 28 May 2010 13:45:26 -0700

On 05/27/10 09:28 PM, Reddy, Joseph wrote:
> When a new address is to be configured, the draft requires the host
> to send NS with with the IPv6 source address set to this address and
> to also include ( must ) the SLLA option
>
> Does this not cause a violation of the address scoping rules ( since
> the destination address is a link local address derived from the RA
> while the source is a global, assuming we want to register a global
> address ) ?

There is no prohibition of combining different address scopes in IPv6. 
RFC 3484 tries to avoid such combinations when the stack needs to select 
a source/destination path for an application, but that is a different 
matter.
In the 6lowpan-nd case the sender and receiver are neighbors, hence the 
RFC 3484 considerations don't apply.

> Is there a reason why the unspecified address is not used for the
> source ( and include the address in the ARO option ) like in classic
> ND ?

RFC 4861 only allows the unspecified source address in NS message for 
the purposes of DAD, which is integral to using multicast packets for DAD.

Is there a reason to use the unspecified address in some new way?

> If this is because you want to include the SLLA option, note
> that this is not really necessary since the link layer source address
> can be deduced by the router from the L2 headers

I think that would be architecturally unsound, because we want IP to be 
able to run over a rich set of datalink technologies, and over time we 
have seen datalinks that do odd things to the addresses in the datalink 
headers. This is now new with IPv6 and ND; arp carries the hardware 
addresses in the ARP header, even though they are also in the Ethernet 
header that encapsulates the ARP header. This seemed to have served us 
well as the Internet has evolved.

> Also, if a host wants to register with multiple routers, it seems
> that each of the routers will end up doing the multihop DaD on the
> address. This will waste bandwidth ( as well as reduce battery life
> of host since the process will be much longer ). Instead, it will be
> useful to allow the host to differentiate between the intial address
> registration ( when DaD is needed ) and subsequent ones. One way to
> do this would be to use the unspecified source address during initial
> registration followed by the actual address for subsequent ones.

A 6LR can trivially tell whether or not it is a re-registration from the 
host - whether or not it already has a Neighbor Cache entry.
If the optional multihop DAD is used, this means that the 6LR can 
respond immediately to the host for a re-registration.

    Erik

---

From: "Reddy, Joseph" <[email-masked]>
Date: Fri, 28 May 2010 18:29:56 -0500

Hi Erik,

>RFC 4861 only allows the unspecified source address in NS message for the purposes of DAD, which is integral to using multicast packets for DAD.

>Is there a reason to use the unspecified address in some new way?

[JSR]
The reason would be the handling of neighbor cache on the parent router. In the current draft, it is possible that an inaccurate neigbor cache entry is temporarily created on a Router and that could lead to potential problems.

Consider a scenario where Host1 registers its address with Router1 and succesfully undergoes multihop DaD

Now suppose Host2 attempts to register the same IP address with Router2. While the multihop DaD is ongoing, Router2 will have a neighbor cache entry with the duplicate IP address ( that actually belongs to Host1 ) and the LL address of Host2 ( note that is necessary for the Router2 to create a neighbor cache entry at this stage, otherwise the SLLA of Host2 would not be available later to send the NA ).

Now lets say that Host2 were to lose connectivity to its default Router1 and it tries to register with a differnet router, say Router2. It will get a duplicate address message from Router2, even though it actually owns the address.

-Regards, Joseph

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: Friday, May 28, 2010 1:45 PM
To: Reddy, Joseph
Cc: [email-masked]
Subject: Re: [6lowpan] NS source address in nd-09

On 05/27/10 09:28 PM, Reddy, Joseph wrote:
> When a new address is to be configured, the draft requires the host to 
> send NS with with the IPv6 source address set to this address and to 
> also include ( must ) the SLLA option
>

There is no prohibition of combining different address scopes in IPv6. 
RFC 3484 tries to avoid such combinations when the stack needs to select a source/destination path for an application, but that is a different matter.
In the 6lowpan-nd case the sender and receiver are neighbors, hence the RFC 3484 considerations don't apply.

> source ( and include the address in the ARO option ) like in classic 

RFC 4861 only allows the unspecified source address in NS message for the purposes of DAD, which is integral to using multicast packets for DAD.

> If this is because you want to include the SLLA option, note that this 
> is not really necessary since the link layer source address can be 
> deduced by the router from the L2 headers

I think that would be architecturally unsound, because we want IP to be able to run over a rich set of datalink technologies, and over time we have seen datalinks that do odd things to the addresses in the datalink headers. This is now new with IPv6 and ND; arp carries the hardware addresses in the ARP header, even though they are also in the Ethernet header that encapsulates the ARP header. This seemed to have served us well as the Internet has evolved.

> Also, if a host wants to register with multiple routers, it seems that 
> each of the routers will end up doing the multihop DaD on the address. 
> This will waste bandwidth ( as well as reduce battery life of host 
> since the process will be much longer ). Instead, it will be useful to 
> allow the host to differentiate between the intial address 
> registration ( when DaD is needed ) and subsequent ones. One way to do 
> this would be to use the unspecified source address during initial 

A 6LR can trivially tell whether or not it is a re-registration from the host - whether or not it already has a Neighbor Cache entry.
If the optional multihop DAD is used, this means that the 6LR can respond immediately to the host for a re-registration.

    Erik

---

From: Robert Cragie <[email-masked]>
Date: Sat, 29 May 2010 12:25:17 +0100

Hi Joseph,

Comments inline, bracketed by <RCC></RCC>

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>

> Now suppose Host2 attempts to register the same IP address with Router2. While the multihop DaD is ongoing, Router2 will have a neighbor cache entry with the duplicate IP address ( that actually be…
<RCC>Maybe it's missing from the spec. but the neighbor cache entry must 
be marked as tentative somehow until registration and multihop DAD is 
complete.</RCC>
> Now lets say that Host2 were to lose connectivity to its default Router1 and it tries to register with a differnet router, say Router2. It will get a duplicate address message from Router2, even th…
<RCC>Do you mean Host1? Again, if DAD isn't complete I would presume 
that Router2 cannot assume any validity about Host2 until it has 
completed its DAD. In the above scenario, Host2 would fail its DAD, 
therefore would have to register a different address.</RCC>
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>
>

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 30 May 2010 05:50:36 -0700

On 05/28/10 04:29 PM, Reddy, Joseph wrote:
>
> Hi Erik,
>
>>> Is there a reason why the unspecified address is not used for
>>> the source ( and include the address in the ARO option ) like in
>>> classic ND ?
>
>> RFC 4861 only allows the unspecified source address in NS message
>> for the purposes of DAD, which is integral to using multicast
>> packets for DAD.
>
> [JSR] The reason would be the handling of neighbor cache on the
> parent router. In the current draft, it is possible that an
> inaccurate neigbor cache entry is temporarily created on a Router and
> that could lead to potential problems.
>
> Now suppose Host2 attempts to register the same IP address with
> Router2. While the multihop DaD is ongoing, Router2 will have a
> neighbor cache entry with the duplicate IP address ( that actually
> belongs to Host1 ) and the LL address of Host2 ( note that is
> necessary for the Router2 to create a neighbor cache entry at this
> stage, otherwise the SLLA of Host2 would not be available later to
> send the NA ).

I see some more care is needed in the specification around multihop DAD. 
In the case of multihop DAD I don't think the 6LR should create a 
Neighbor Cache entry until DAD has been verified. A possible way to 
handle not forgetting the SLLA (to be able to respond as you point out) 
would be to create a NCE but mark it as "unverified". Then an unverified 
NCE can be be used to send the response to the host, and if the response 
was "ok" then the unverified NCE would become a normal NCE, otherwise it 
would be deleted.

This means that in the case of two hosts attached to the same 6LR try to 
use the same IP address at the same time, then the 6LR might end up with 
two unverified NCEs for the same IP address; at most one of those will 
"win" as determined by the 6LBR(s). Thus when a response comes from the 
6LBR the 6LR will use the IPv6 address plus the EUI-64 to find any 
"unverified" NCE.

In any case, I don't see how using the unspecified source address would 
make this any easier. The fundamental issue is that an 6LR needs to 
retain sufficient information about a host while multihop DAD is in 
progress, and not let that "in progress" information be confused with 
authoritative and verified registrations.

    Erik