Re: draft-bourbaki-6man-classless-ipv6-00 - method feasible

[Alexandre Petrescu <[e-mail]>]

Le 13/06/2017 à 04:22, Manfredi, Albert E a écrit :
> -----Original Message----- From: ipv6 [mailto:[e-mail]]
> On Behalf Of Brian E Carpenter
> 
>>> there's no reason why the IID should be link-type dependent.
>> 
>> I believe that is simply false unless you want to go back to the 
>> era of DIP switches with instructions to users to a) choose an IID
>> length for their new subnet b) set the DIP switches on every device
>> to select that length c) then plug and play.
>> 
>> Otherwise LL addresses cannot be formed consistently on the whole
>> link.
> 
> Why so, Brian? I've already described one easy technique: the host
> can create IIDs of any length, based on an algorithm that we might
> just be debating for a long time, but fundamentally can be quite
> straightforward. And then the host chooses the correct IID to use for
> SLAAC, based on the RA it just received.
> 
>> OK, that is caricature, but without a substantial reworking of 
>> RFC4862 I believe that is essentially what we would need, in an
>> automated version, before SLAAC can start.
> 
> 1. Host can create, in real time, IIDs of length 128 to 0 bits. To do
> this, for SLAAC, it SHOULD not be difficult IMO. One possibility:
> create random 128-bit value, then use a simple truncation algorithm
> to reduce the number of bits to the required value, at the
> appropriate time.
> 
> 2. Host waits for RA.
> 
> 3. Host determines prefix length after receiving RA, using the
> equation:
> 
> IID length = 128 - prefix length
> 
> 4. Host generates 128-bit SLAAC address. If we started with the
> 128-bit random number, just truncate as needed.
> 
> 5. Perform DAD, as already prescribed.

This method seems feasible to me.

It would allow WiFi terminals to connect to a smartphone that was
advertised a /64 on its LTE link and made a /65 for the WiFi interface.
  The RA would contain that /65 and the WiFi terminal would make an IID
of length 63.

This same WiFi terminal is backwards compatible: it could also connect
to other WiFi networks where the RA has a prefix /64.

Alex

> 
>> Anway, all this is empty talk as long as the addressing 
>> architecture *requires* 64 bits rather than *recommending* 64 
>> bits.
> 
> True, but anything that *requires* something, based on a premise that
> has all but been discarded, doesn't hold much credibility anymore.
> The fallout from having deprecated that premise needs to be
> considered. A better future can result, as in this case (IMO). I
> think there's something in philosophy that addresses just this sort
> of situation. Where the general consensus of an argument can change
> 180 degrees, if more information on the underlying premises is
> presented.
> 
> Bert
> 
> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list [e-mail] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>