Subject: RE: New Version Notification for draft-chakrabarti-nordmark-6man-efficient-nd-05.txt

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 1 Mar 2014 18:09:03 +0000

Hello Jinmei:

You are correct, that would be a chicken and an egg problem.
In fact, the draft clarifies that the initial RS will have to be multicasted on the link. In section 2:

      Remove the use of multicast for DAD and Address Resolution (no
      multicast NS messages), and remove periodic multicast RAs.  Some
      multicast RS and RA are needed to handle the arrival of new hosts
      and routers on the link since they need to bootstrap to find each
      other.

The multicast is to all routers as opposed to all hosts, and we can expect to improve at least the support of that multicast group.
In practice, a number of WiFi APs out there just block RS towards the wireless side. 

We'll note also that the multicast is of linklocal scope. IOW, for a multilink Subnet, only one link will be impacted. 
This property is leveraged in RFC 6775 for LLNs with the expectation that every device can reach a router over its link, which in route-over is one radio hop.

Cheers,

Pascal

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of ????
> Sent: vendredi 28 février 2014 23:54
> To: Erik Nordmark
> Cc: IETF IPv6
> Subject: Re: New Version Notification for draft-chakrabarti-nordmark-6man-
> efficient-nd-05.txt
> 
> At Thu, 27 Feb 2014 22:08:27 +0100,
> Erik Nordmark <[email-masked]> wrote:
> 
> > But we seemed to not have edited the rest of the draft correctly
> > around DAD, including the bootstrapping section.
> > As the draft currently stands DAD for link-locals is (or "can be"
> > given the lack of editorial clarity) replaced by NS/ARO. But address
> > resolution for link-local targets needs to be done for using multicast NS.
> 
> I don't understand how it works in the bootstrap stage.  To send the NS/ARO for
> a link-local address (on bootstrap), the host should first know the registrar's
> address.  But the host can't get the information by unicast RS-RA exchange since
> the source address of the RS would need to be the link-local address to prove
> unique.  Or am I misunderstanding your intent?
> 
> --
> JINMEI, Tatuya
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 01 Mar 2014 14:01:03 +0100

On 2/28/14 11:53 PM, 神明達哉 wrote:
>
> I don't understand how it works in the bootstrap stage.  To send the
> NS/ARO for a link-local address (on bootstrap), the host should first
> know the registrar's address.  But the host can't get the information
> by unicast RS-RA exchange since the source address of the RS would
> need to be the link-local address to prove unique.  Or am I
> misunderstanding your intent?
That part isn't fully fleshed out in the draft.

To have a unicast RA prior to having registered the link-local address, 
the router needs to use the SLLA option in the RS - this would be the 
same mechanism as in the draft for sending errors to NS/AROs.

Thus the RS can have an unspecified source address while containing a 
SLLAO; something which isn't allowed in 4861 AFAICT. So need to look at 
mixed mode issues here.

    Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 1 Mar 2014 21:43:30 +0000

A variation could be to add a new option in the RS with both the linklocal and the slla that the device wishes to use.

A NEAR would eventually perform the DAD on behalf in case of mixed mode. It could create a temp nce and answer unicast. If success then the node could register that address.

What do you think?

Pascal

> Le 1 mars 2014 à 21:48, "Erik Nordmark" <[email-masked]> a écrit :
> 
> To have a unicast RA prior to having registered the link-local address, the router needs to use the SLLA option in the RS - this would be the same mechanism as in the draft for sending errors to NS/AROs.
> 
> Thus the RS can have an unspecified source address while containing a SLLAO; something which isn't allowed in 4861 AFAICT. So need to look at mixed mode issues here.
> 
>   Erik
>

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 02 Mar 2014 13:47:07 +0000

> A variation could be to add a new option in the RS with both the linklocal and the slla that the device wishes to use.
We wouldn't need a new option - in a slightly different context Samita
suggested we might want to send the ARO in the RS, which would solve the
above.

> A NEAR would eventually perform the DAD on behalf in case of mixed mode. It could create a temp nce and answer unicast. If success then the node could register that address.
The mixed mode support would be the same whether we register with RS or NS.

So this sounds like a reasonable approach.

Erik

---

From: 神明達哉 <[email-masked]>
Date: Sun, 2 Mar 2014 16:40:52 +0000

At Sat, 01 Mar 2014 14:01:03 +0100,

> same mechanism as in the draft for sending errors to NS/AROs.

What if the link-local address is a duplicate and that's because the
link-layer address is a duplicate?  If the unicast RA is supposed to
include an ARO whose status field is 1 and be sent to the (duplicate)
link-local address, it's not guaranteed the RA is delivered to the
node that sent the RS.

The same question applies to the NS/NA exchange attempting to replace
the traditional DAD.

--
JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 03 Mar 2014 15:01:55 +0000

> link-local address, it's not guaranteed the RA is delivered to the
We can not detect and handle duplicate MAC addresses using DAD in general.

Even back when we first defined DAD we knew it could handle MAC address 
duplicates for Ethernet (assuming certain device driver behavior), but 
probably not on FDDI and Token Ring (due to how the ring maintenance 
worked).

More recent work like dad-proxy assumes that the MAC addresses  are not 
duplicate, and the loopback case needs special care even when MAC 
addresses are unique.

Using explicit registrations doesn't really change that. The 
registration needs some unique id (be it an EUI-64 or DCHP DUID) that is 
unique to tell apart a duplicate and a registration refresh. If your MAC 
address is not unique then your EUI-64 (or MAC address based DUID) is 
likely to also not be unique.

    Erik

---

From: 神明達哉 <[email-masked]>
Date: Mon, 3 Mar 2014 17:57:55 +0000

At Mon, 03 Mar 2014 15:01:55 +0000,

> likely to also not be unique.

I'm not sure if I follow your logic.  Probably as you noted above
yourself, the original DAD took into account handling MAC address
duplicates, even if it may not always work.  On the other hand,
efficient-nd can never handle MAC address duplicates.  Since
efficient-nd seems to cover more general (even if not all) networks,
claiming it eliminates the need for multicast in specific cases
including DAD, I think it's important to clarify what it trades for it
(which is, in this case, the inability of handling MAC duplicates).

--
JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 06 Mar 2014 17:18:51 +0000

>> likely to also not be unique.

Jinmei,
sorry for being slow in responding.

>> efficient-nd can never handle MAC address duplicates.

Any mechanism (be it ARO or DHCPv6) which allows a node to register 
something depends on a unique way to identify the registrants (the nodes).
For example, with DHCPv6 you can use a DUID which is MAC address plus 
timestamp.
Since two hosts with the same MAC address are likely to have picked a 
different timestamp, the DHCPv6 server can tell them apart (ditto for 
efficient-nd-05 using ARO - identical mechanism).

However, if there is no such unique identifier (except the MAC address 
itself) then they can't be told apart.

The second issue is how the host can communicate (with the 
routers/relays to do ARO/DHCPv6) if at L2 they do not have a unique 
link-layer address. They need to be able to receive response packets. 
That is hard in general. FWIW in 4861/62 that was solved by the DAD 
response (when a duplicate) being multicast at L2.

>> Since
Yes, it makes sense to clarify that.

    Erik

---

From: 神明達哉 <[email-masked]>
Date: Tue, 18 Mar 2014 08:39:13 -0700

At Thu, 06 Mar 2014 17:18:51 +0000,

> something depends on a unique way to identify the registrants (the nodes).
[...]
> response (when a duplicate) being multicast at L2.

Right, so what I wanted to say in the original context was:
- the original DAD can detect MAC address duplicates thanks to the use
  of multicasting
- efficient-nd cannot do that as long as its main purpose is to avoid
  multicasting in the first place

Or in other words, "avoiding multicast" and "performing DAD" cannot
completely be achieved at the same time in efficient-nd.  And hence,

--
JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 19 Mar 2014 12:22:31 -0700

> - the original DAD can detect MAC address duplicates thanks to the use
With a caveat or two. This only works on link-layers where the L2 will 
be functioning where there are duplicate MAC addresses (the duplicate 
MAC address can't prevent the link/interface from coming up at L2). And 
the link-layer must not filter out received L2 frames just because the 
MAC header contains your own MAC address, while the link-layer must not 
loop back a copy of the multicast frames you send.

> completely be achieved at the same time in efficient-nd.
I don't know if I'd call it "performing DAD" since what we are talking 
about is "performing MAD - Mac Address Duplicate Detection".

I don't think the multicast is the fundamental architectural.

There are two issues:
1. Being able to tell the difference between a host moving and redoing 
DAD from a different location (e.g., on a different switch port), and 
another host trying to use the same MAC address and IPv6 address.

2. If a duplicate is detected, how does the system deliver that 
notification to one (or both) of the parties which have the same MAC 
address.

In 4861/62 the link-layer constraints in my caveat above handle #1. In 
general one can't rely on the MAC address to tell them apart if you want 
to do MAD. But it can be done using unique characteristics beyond the 
MAC address (be that a random nonce as in enhanced-nd, some other 
factory-assigned globally unique identifier, or something large, random 
and stable like a public key).

In think #2 is the main area where multicast is helpful. However, it 
isn't always required. For instance, in a SAVI type setup the device can 
see that the two hosts are on different ports, and send out DAD error a 
particular port to target one of the two conflicting nodes. Multicast 
wouldn't be required for such a DAD error. But it assumes that the 
detector is placed in the topology where some other binding anchor can 
be used - different L2 ports in this example.

If you were to deploy efficient-nd's ARO in a switched Ethernet network 
(with learning bridges) the duplicate MAC will be detected and there is 
a pretty good chance it would be reported to the host - the NS/ARO sent 
to the router will cause L2 learning to send the error back to the most 
recent source of the MAC address. (But the original user of the 
duplicate MAC would see some disruption.)
And the router can log the existence of a duplicate address.
> And hence,
Sounds like it will require an essay instead of a single sentence...

    Erik