Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets

[Christopher Morrow <[e-mail]>]

On Fri, Feb 24, 2017 at 12:09 PM, Alexandre Petrescu <
[e-mail]> wrote:

>
>
> Le 24/02/2017 à 17:27, Christopher Morrow a écrit :
>
>>
>>
>> On Fri, Feb 24, 2017 at 10:48 AM, Alexandre Petrescu
>> <[e-mail] <mailto:[e-mail]>>
>> wrote:
>>
>>
>>
>> Le 24/02/2017 à 15:59, Christopher Morrow a écrit :
>>
>>
>>
>> On Fri, Feb 24, 2017 at 9:09 AM, Alexandre Petrescu
>> <[e-mail] <mailto:[e-mail]>
>> <mailto:[e-mail]
>> <mailto:[e-mail]>>> wrote:
>>
>>
>> A question to Windows is the following: what prefixlen does it set
>> when the end user manually assigns an address on an interface
>> without specifiying a prefixlen?
>>
>>
>> I don't think this matters... 'end users' will in almost all cases
>> just attach and get connectivity.
>>
>>
>> Let me go next in cycle: what does linux do when one ifconfig add an
>> IPv6 address without telling the plen?  Is it adding an entry in the
>> rt table?  Which plen?  Is that plen normal?
>>
>>
>> still don't think this matters. If a user messes up what they type,
>> they messed up. if the instructions aren't complete, they aren't
>> complete and there will be mistakes. An interface configuration
>> requires all proper parameters be set, or problems will arise.
>> Assumptions about current and future behavior are proven wrong time
>> and again.
>>
>> non-deterministic behavior over time is the hallmark of this
>> space... please do not rely on defaults for hand-managed/bespoke
>> configurations if you expect things to work reliably and repeatably.
>>
>
> That means the following: Windows please make the plen parameter
> mandatory.  Dont leave it optional only to subversively set it to 64.
> That's a software bug because nobody asks you to set the plen to 64 when
> the end user does not specify one.
>
> I guess the same bug is is in BSD, linux and what have you.
>
>
yes, I think so.. for linux:
$ sudo ip -6 addr add 2001:700:4::1 dev em1

gets me:
 inet6 2001:700:4::1/128 scope global

so that actually seems correct.


>
>> If they are in a place where someone says: "Hey, you should go
>> if/ipconfig ...." then .. they are 'consenting adults' and can do
>> whatever they please.
>>
>>
>> I assume you assume that ip/ifconfig by consenting adults means the
>> adults type a plen in the CLI, right?
>>
>>
>> sure, or a script/program/etc does this, it's not important how the
>> 'ifconfig' happens, it's important that when it happens the right
>> parameters are passed to the 'ifconfig' command.
>>
>
> I agree.  If 'ifconfig' silently assumes 64 then that assumption is
> wrong.  The ifconfig programmer should take that as a software bug.
> It's not an RFC that requires them to put 64 there.
>
>
ok


> That makes it mandatory that the CLI _requires_ a plen, right?  That
>> CLI should not allow silence for a plen parameter.
>>
>>
>> sure, or you are at the mercy of the implementor of that command:
>> Today I like /64! It's tomorrow and now I like /62!!
>>
>> don't rely on defaults.
>>
>
> I agree.
>
> Because silent plen means 64.  And I dont think it's right to assume
>> a by-default 64 plen.  Because many people think 64 is right and
>> others think it's wrong, there does not seem to be a commonly agreed
>> 'by default' value for plen.
>>
>>
>> correct, so.. be specific in your configuration effort please...
>> which again, means that the 'what is the default?" conversation is
>> moot.
>>
>
> I am not asking what is the default.
>
> I am saying that apparently numerous implementations out there consider
> the default to be 64.  This consideration is wrong.
>
>
yes, I agree with you here.


> A 'default' value is something that everybody agrees with.  For example,
> one can leave out '::' from a command line adding a default route and
> just say 'default'.  There is an agreed standard that says that
> 'default' is '::'.
>
> But there is by far no single standard that says the default prefix
> length is 64.
>
> That's why it's a bug.
>
> It's like boxes with pre-defined passwords admin/admin.  The local
> programmer imagined it a good 'default' but never asked around the
> validity of such assumption.  And that creates problems.


ok, cool, i think we agree on all of this at least :)


>

Alex
>
>
>
>>
>> Alex
>>
>>
>>
>> again the proposed text (now 175+ messages back) really covers this
>> already..
>>
>>
>>