Re: [v6ops] draft-jaeggli-v6ops-indefensible-nd

We have greatly improved the ARO at 6lo and tried in the process to alleviate Lorenzo ‘s concerns about it being an undesirable way to remove freedom of address formation. We also discussed Bob’s concerns on IPv6 stability at length so hopefully we are passed that as well.

The new ARO (EARO) is clearly intended to protect the address ownership. The NP AD draft associates a crypto token to the registration but does not constrain the IID like SEND did. 

The EARO is already referenced by a number of drafts (at ROLL 6lo and RIFT) as the abstract way for a host to announce its addresses to selected routers and get services back, eg routing or ND proxy.

Regards,

Pascal

> Le 11 sept. 2018 à 08:49, Erik Kline <ek=40google.com@dmarc.ietf.org> a écrit :
> 
>> On Tue, 11 Sep 2018 at 15:34, Ole Troan <otroan@employees.org> wrote:
>> 
>> Erik,
>> 
>>>> On 11 Sep 2018, at 08:22, Erik Kline <ek@google.com> wrote:
>>>> 
>>>> On Tue, 11 Sep 2018 at 15:15, Ole Troan <otroan@employees.org> wrote:
>>>> 
>>>> You might want to include that this problem has been solved with a stateful address assignment mechanism like DHCP, possibly combined with SAVI.
>>>> 
>>>> The ND ARO option would also have solved this.
>>>> 
>>>> Or you could deploy P2P Ethernet, where there is no address resolution..
>>>> 
>>>> Depending on DAD for this lie Lorenzo proposed seems ill-advised. It’s even less robust in wired networks (blocked ports).
>>> 
>>> But...in such a network NS/NA works?  (alternatively: what does
>>> "blocked" mean here)
>> 
>> NS/NA has retransmission.
>> Blocked as in 802.1D. Default 30s from link-up until port will switch user traffic.
> 
> Do hosts receive RAs during this 30s window?  If not, then the
> blocking affects DAD for link-local addresses, but not necessarily for
> GUAs.
> 
> NOTE: I am most definitely /not/ attempting to argue that DAD is reliable.  ;-)
> 
> I had a notion about matching forwarding addresses not in cache
> against the MLD info associated with the /104 for a given forwarding
> destination address.  Seems like routers gathering MLD data might use
> that list to prioritize forwarding for destinations not yet in the
> neighbor cache.
> 
>> DAD is unreliable for lots of reasons . Didn’t we write a draft on that?
> 
> https://tools.ietf.org/html/draft-yourtchenko-6man-dad-issues ?
> 
>> Ole
>> 
>> 
>>>> 
>>>>> On 10 Sep 2018, at 16:25, Ron Bonica <rbonica@juniper.net> wrote:
>>>>> 
>>>>> Folks,
>>>>> 
>>>>> Each week between now and IETF 103, we will review and discuss one draft with an eye towards progressing it.
>>>>> 
>>>>> This week, please review and comment on draft-jaeggli-v6ops-indefensible-nd.
>>>>> 
>>>>>                                    Fred and Ron
>>>>> 
>>>>> _______________________________________________
>>>>> v6ops mailing list
>>>>> v6ops@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>> 
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> v6ops@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops