Re: Objection to draft-ietf-6man-rfc4291bis-07.txt

[Mark Smith <[e-mail]>]

On 27 Feb. 2017 21:23, "Alexandre Petrescu" <[e-mail]>
wrote:



Le 26/02/2017 à 20:24, Brian E Carpenter a écrit :

> Aelexandre, On 27/02/2017 07:55, Alexandre Petrescu wrote: ...
>
>> I would not agree if I read "/64 is RECOMMENDED".
>>>>
>>>
>>> There I think you are wrong.
>>>
>>
>> I think I am wrong depending on what tense we use: is it about the
>>  future or about the past?
>>
>> When we say "is RECOMMENDED" and it becomes an RFC then that will
>> effectively be recommended during the next 10 years or so, until
>> next RFC update.  I fully disagree with this plan.  It will
>> comfort the cellular operators to continue assigning a single /64
>> to one User Terminal.
>>
>> It is the value that today allows portable interoperable host
>>> software (on IEEE 802.1 or 802.11 media)
>>>
>>
>> (for 802.1 and 802.11 media - there is much I can say here -
>> basically IPv6 stacks interface to EthernertII headers, no 802.1
>> nor 802.11, but that's another matter; wireshark and RFC2464 show
>> that).
>>
>> I would like to add that, in addition to the Ethernet I suppose
>> you want to talk about by saying 802.1 and 802.11, the 64 limit is
>> so only if SLAAC is there too.
>>
>> If one uses only Ethernet (no SLAAC) then the 64 is not set in
>> stone.
>>
>> If one uses only SLAAC (no Ethernet) then the 64 is not set in
>> stone.
>>
>> If one uses SLAAC-on-Ethernet then 64 is set in stone, and only
>> then.
>>
>> From this, to make a general IPv6 Architecture Architecture that
>> says that 64 is RECOMMENDED default there is a long way.
>>
>
> You didn't pay attention to my phrase "portable interoperable host
> software".
>
> I carry my laptop and my Android phone around quite a lot. I want
> them to just work when they find themselves on a new IPv6 network.
> Given that we never put in place dynamic parameterisation of the
> 802.1/802.11 IID length, that's only possible because the various
> software writers involved over the years all implemented /64. End of
> message.
>

I see.

We want the laptop and android to continue work that way - it is good.
But could they just rely on RFC2464?  Isn't the IPv6 Addressing
Architecture too high a promotion for just that case?

IMHO maybe we are trying to improve an earlier 4291 paragraph whose
initial intention may have been good, but is not consensual.



Just to be clear, consensus doesn't mean unanimous.

https://tools.ietf.org/html/rfc7282

That par
is "All Global Unicast addresses other than those that start with binary
000 have a 64-bit interface ID field".

There are additional messages that circulated in private, and that have
not been posted publicly, about the validity of an "Interface ID"
altogether.  What's the meaning of an Interface Identifier when one can
have same IID on different interfaces?


Answered in RFC4291.



Or is the laptop/android use-case actually needing a "Host
Identifier" (not an IID)?

Has the option of removing this 4291 paragraph altogether been
considered (instead of improving it)?

Alex



> Brian
>
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------