Re: [DNA] Consensus call for adoption of TSLLAO as a working group item

[Christian Vogt <chvogt@tm.uka.de>]

I think there is a good reason for moving this draft towards the 
standards track:

The draft specifies the use of a TSLLAO in Neighbor Solicitation 
messages, which is in particular useful in conjunction with Optimistic 
DAD.  This is something the DNA Protocol 3 does not cover, so it makes 
sense to publish the TSLLAO draft separately.

- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/


Greg Daley wrote:
> 
> Hi,
> 
> This is the start of a two week consensus call as
> to whether Tentative Source Link-Layer Address Options
> should be adopted as a working group item in DNA WG.
> 
> These are currently documented in: draft-daley-ipv6-tsllao-02.txt
> 
> While there was some interest in this at the IETF64 session,
> the chairs recognize that few people had prepared to discuss
> this document before the session.
> 
> Any feedback or queries about this consensus call can be
> sent to the chairs.
> 
> The consensus call will end 12:01am Saturday 3rd December UTC
> 
> The document can be found at:
> 
> http://www.ietf.org/internet-drafts/draft-daley-ipv6-tsllao-02.txt
> 
> Here's a (quick) summary of the discussion from the minutes
> (from JAK, with some recollections added by GD.  Further
> merged minutes will be available shortly).
> ---------
> ...
> 
> Suresh
> TSLLAO
> 
> Normatively referenced by two documents, which are WG docs
> 
> IPv6 chairs want this done in DNA cause IPv6 WG is going into hibernation
> 
> Greg will present
> (briefly summarizes draft)
> 
> Problem with SLLAO is that it overrides NC entry, would like to get
> unicast back to an optimistic address
> 
> TSLLAO does not destroy NC entry
> 
> Implementation in Linux available from Greg
> 
> Suresh
> RS can't be unicast without optoin, need to do NS. Necessary to have
> this done, IANA allocation
> 
> Mohan
> Solution all you need is Mac address for repsonse for RA, create NC
> entry for packet. Optimistic DAD is written such that create an NC
> entry if you don't have it.
> 
> Greg
> Can send unicast packet back without a Neighbour Cache entry.
> 
> Mohan
> Does create entry if no entry is there?
> 
> Greg
> With oDAD, small chance of collision, if there's a collision, we want
> operations to be safe for original address owner, advantage if temporary,
> won't create or modify an entry (GD: if an entry exists). MAC binding will
> be delivered to another destiantion if there is another NC entry.
> 
> Suresh
> WG item - 8 hands
> none against
> 
> confirm on the list.
> 
> Greg
> Know it's a late agenda item, not trying to shove something through.
> 
> Suresh
> Should this be in a separate document? 5 hands for
> Part of solution document? 2
> 
> confirm on list
> 
> (discussion of whether separate or same)
> 
> ---------
> 
> 
> 
> Please be aware that if adopted, further discussion on whether
> the document should stand-alone or be merged into an existing
> document will occur, with another consensus call.
> 
> Please send comments to the list.
> 
> Greg