Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

[Alexandre Petrescu <[e-mail]>]

Le 22/02/2017 à 00:23, Brian E Carpenter a écrit :
> On 22/02/2017 11:58, Job Snijders wrote:
>> On Wed, Feb 22, 2017 at 11:44:42AM +1300, Brian E Carpenter wrote:
>>> On 21/02/2017 23:13, Job Snijders wrote:
>>>> On Tue, Feb 21, 2017 at 02:11:15PM +1300, Brian E Carpenter
>>>> wrote:
>>>>> On 21/02/2017 13:19, Job Snijders wrote:
>>>>>> On Thu, Feb 16, 2017 at 09:40:01AM +0100,
>>>>>> [e-mail] wrote:
>>>>>>> There are many reasons for the 64 bit boundary. -
>>>>>>> Allowing identifier locator split: 8+8 / GSE that led to
>>>>>>> ILNP and NPT66
>>>>>>
>>>>>> Irrelevant.
>>>>>
>>>>> Not really. They are both running code. You may not want them
>>>>> in *your* network but that isn't the point. Some people want
>>>>> them.
>>>>>
>>>>> And there is a lot of other running code too, not just SLAAC
>>>>> which is mandatory to implement in every IPv6 host. So this
>>>>> actually trumps all the other arguments: it's 64 bits because
>>>>> it's 64 bits.
>>>>
>>>> When someone utters the phrase "it is X because it is X", the
>>>> rhetorical imperative seems to be to dismiss further
>>>> conversation (perhaps any internal dialogue as well, which may
>>>> be the primary purpose). "It is what it is" therefore, there’s
>>>> nothing more to be said about it...
>>>>
>>>> Except when it's not 64 bits?
>>>
>>> That wasn't quite my intention. I just wanted to underline that
>>> (like it or not) it was set at 64 bits many years ago and a lot
>>> has been built on that.
>>>
>>> ...
>>>> I've looked at all configured IPv6 addresses on AS 2914
>>>> equipment. Interestingly enough, the below table is a
>>>> reflection of not only NTT's own addressing, and (since
>>>> AS2914's core function is to connect networks to each other)
>>>> also of its peers and customers. In the end, whatever makes the
>>>> thing work is the thing that will be configured.
>>>>
>>>> /127 - 22% /126 - 52% /125 - 0,9% /124 - 0,5% /120 - 0,04% /112
>>>> - 0,02% /64  - 23%
>>>
>>> Thanks, that's interesting. So 23% of the devices might have
>>> RFC4291-compliant IIDs. The others are configured with 128 bit
>>> IPv6 addresses. Is that correct?
>>
>> The percentage is not the percentage of devices, but the percentage
>> of interconnections. In all instances the addresses are staticly
>> configured.
>
> OK, but from the outside I can't know that for the /64 subnets.
>
>> Back to my example from earlier, to make sure we are on the same
>> page, this is output from a standard Linux machine:
>>
>> job@tardis:~$ sudo ip -6 addr add 2001:728:1808:1::21/126 dev eth1
>> job@tardis:~$ sudo ip -6 addr show dev eth1 3: eth1:
>> <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 inet6
>> 2001:728:1808:1::21/126 scope global valid_lft forever
>> preferred_lft forever inet6 fe80::20d:b9ff:fe41:d4f5/64 scope link
>> valid_lft forever preferred_lft forever job@tardis:~$
>>
>> Most network engineers would call the above example "configuring a
>> /126 on an interface" - but am I understanding correctly that in
>> your taxonomy you would call this "configuring a 128 bit IPv6
>> address"?
>
> Well that does two things: configures a 128 bit address (as Chris
> points out, *all* addresses are 128 bits, duh) and associates a
> prefix length with it, which afaik is optional.

The prefix length is not optional.  There is no system out there on
which one could configure a 128bit address without explicitely telling
'/128' or '/64' or '/something-else'.

By specifications, I think only DHCPv6 specs say that the address
assigned to a Client has no prefix length.  In practice though, the
address assigned by DHCPv6 w/o  prefix length gets a 'by default' prefix
length often hardcoded as '/64'.

> But the interface has already auto-configured a link-local address,
> with a 64 bit IID. So yes, that's exactly what I mean.

Which brings back: the LL address should have a prefix length or no?  If 
yes should it be /64 (2464bis) or /10 (4291bis)?

Linux sets it at /64 by default... and I disagree with it, 4291bis 
disagrees too.

Alex

>>> That being so, perhaps the words that are missing are "The IID
>>> length requirement does not apply to interfaces that are
>>> explicitly configured with 128 bit addresses." Because the
>>> requirement is meaningless for such interfaces.
>>
>> The terminology might confuse some people, as in common language
>> when one configures "a /128", or 'a 128 bit address', it usually
>> means you are configuring something like a loopback address.
>>
>> Perhaps:
>>
>> "The IID length requirement does not apply to interfaces that are
>> explicitly configured without autoconfiguration."
>>
>> (perhaps even remove the word 'explicitly')
>>
>> "The IID length requirement does not apply to interfaces that are
>> configured without autoconfiguration."
>
> Personally I think that's right. (However, if you manually configure
> an address that matches a pre-existing prefix announced by an RA, it
> will be assumed to belong to that prefix. I've done that by hand on
> Windows, not sure I've done it in Linux.)
>
> Brian
>
>