Subject: draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets

From: Nick Hilliard <[email-masked]>
Date: Thu, 23 Feb 2017 19:00:13 +0000

as it's currently worded, draft-ietf-6man-rfc4291bis seems to prohibit
the implementation of any interface netmask != /64:

>                                           However, the Interface ID of
>    all unicast addresses, except those that start with the binary value
>    000, is required to be 64 bits long.

This has substantial operational consequences in the ipv6 world because
if it's implemented as stated, it will cause production ipv6 networks to
break.

The ipv6 operational community may have opinions on the wisdom of
mandating new behaviour which would cause their networks to fall over,
so it would probably be a good idea to notify v6ops@ietf about the
existence of this draft so that the folks over there get a look-in
before a consensus call is made. As far as I can tell, this notification
never happened.

Nick

---

From: Gert Doering <[email-masked]>
Date: Thu, 23 Feb 2017 20:07:30 +0100

Hi,

> if it's implemented as stated, it will cause production ipv6 networks to

Unless I'm totally mistaken this wording has been in "the appropriate
RFC" (4291?) since the beginning of time.

Well, 4291 only mentions this in passing, and points to 3587 [GLOBAL], 
which points to [ARCH] with this sentence

   [ARCH] also requires that all unicast addresses, except those that
   start with binary value 000, have Interface IDs that are 64 bits long
   and to be constructed in Modified EUI-64 format.

[ARCH] is 3513, and states

   For all unicast addresses, except those that start with binary value
   000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

which very much sounds like the sentence above.

> before a consensus call is made. As far as I can tell, this notification

It's not a new mandate - but doing this document, a discussion might
be in order on whether it should still be worded as strictly.

But since nobody seemed to care for the last 14 years (3513 is 
standard track, published April 2003), why should people or vendors
bother to follow RFC mandates now...?

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Job Snijders <[email-masked]>
Date: Thu, 23 Feb 2017 20:08:46 +0100

> before a consensus call is made. As far as I can tell, this notification

This is not 'new', but it is a re-iteration of (in my opinion) a
specification of a non-optimal addressing architecture.

Aside from the newness, I agree with you. I would've hoped that when a
document like this is revised after 10+ years, people would think to ask
and include in dialogue the actual ipv6 operators whether reality is
aligned with the documented architecture.

rfc4291 (2006) "For all unicast addresses, except those that start with
                the binary value 000, Interface IDs are required to be
                64 bits long and to be constructed in Modified EUI-64
                format."

rfc3513 (2003) "For all unicast addresses, except those that start with
                binary value 000, Interface IDs are required to be 64
                bits long and to be constructed in Modified EUI-64
                format.

rfc2373 (1998) "The format prefixes 001 through 111, except for
               Multicast Addresses (1111 1111), are all required to have
               to have 64-bit interface identifiers in EUI-64 format.
               See section 2.5.1 for definitions."

Kind regards,

Job

---

From: Mark Smith <[email-masked]>
Date: Fri, 24 Feb 2017 07:42:21 +1100

>>    000, is required to be 64 bits long.

The thing is this is not new text, it has been in RFC4291 for 11
years. c.f., 2.5.1.

It can't be changed without invalidating all of the other RFCs that
have utilised 64 bit identifiers.

> if it's implemented as stated, it will cause production ipv6 networks to

Going by the millions of IPv6 deployments now, it has been implemented
as stated.

> mandating new behaviour which would cause their networks to fall over,

There is and should be no new behaviour in RFC4291bis, it is a tidy up
to advance it along the standard track.

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Gert Doering <[email-masked]>
Date: Thu, 23 Feb 2017 23:05:31 +0100

Hi,

> have utilised 64 bit identifiers.

Except for the few that explain how to use /126 or /127, right?

Gert Doering
        -- NetMaster

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 23 Feb 2017 22:14:49 +0000

> RFC" (4291?) since the beginning of time.

it has, but it was updated over the years by several other drafts which
proposed the use of other appropriate interface netmasks, including e.g.
rfcs 6164 and 7608.  The importance of 7608 is that netmasks longer than
/64 have no relevance unless there are interface netmasks longer than /64.

> bother to follow RFC mandates now...?

If the IETF mandates something that's both unenforceable and which will
cause breakage if implemented, this makes the IETF look rather foolish.

Nick

---

From: Pierre Pfister <[email-masked]>
Date: Thu, 23 Feb 2017 23:43:52 +0100

> Le 23 févr. 2017 à 21:42, Mark Smith <[email-masked]> a écrit :
> 

And during those 11 years. Nobody implemented this rule specific to ::/3.

> have utilised 64 bit identifiers.

Those "other RFCs" have nothing to do with being part of ::/3 or not.
They require an interface identifier of 64 bits long.
The fact that a protocol does not work in some conditions does not invalidate the protocol.
e.g. the fact that SLAAC over Ethernet doesn't work when IID is not 64 doesn't mean
the IID could not be 64 bits long. It just means that under those conditions, SLAAC would not work.
And those conditions are perfectly well defined in those "other RFCs".

- Pierre

---

From: Mark Smith <[email-masked]>
Date: Fri, 24 Feb 2017 12:40:46 +1100

Those "other RFCs" have nothing to do with being part of ::/3 or not.
They require an interface identifier of 64 bits long.
The fact that a protocol does not work in some conditions does not
invalidate the protocol.
e.g. the fact that SLAAC over Ethernet doesn't work when IID is not 64
doesn't mean
the IID could not be 64 bits long. It just means that under those
conditions, SLAAC would not work.
And those conditions are perfectly well defined in those "other RFCs".

A non-SLAAC example.

"Unicast-Prefix-based IPv6 Multicast Addresses"

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

That example and many others are described in

"Analysis of the 64-bit Boundary in IPv6 Addressing"

https://tools.ietf.org/rfc/rfc7421

Surely everybody here saying change it or abandon it have read that
RFC so they fully understand the consequences of what they're
suggesting, right? I'm pretty sure it has been referenced in at least
one version of the text I've seen in the discussion.

- Pierre

---

From: Xing Li <[email-masked]>
Date: Fri, 24 Feb 2017 10:37:44 +0800

> Except for the few that explain how to use /126 or /127, right?

+1, plus exceptions for the IPv4-translatable IPv6 address defined in 
RFC6052. I suggest just provide pointers to those RFCs in rfc4291bis. xing

---

From: Randy Bush <[email-masked]>
Date: Fri, 24 Feb 2017 10:18:56 +0700

> But since nobody seemed to care for the last 14 years

this is false.  some people have been fighting this for 20 years.
though the first years were more concentrated on fighting the TLS/NLA
insanity, which makes this /64 mess look minor.  for those of us trying
to deal with classful ipv6 for the last 20 years, this /64 issue is the
last clean-up.

randy

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 23 Feb 2017 22:23:38 -0500

> to deal with classful ipv6 for the last 20 years, this /64 issue is the
The original message in the thread about this draft:
" > The IESG has received a request from the IPv6 Maintenance WG (6man) to
> consider the following document:
> - 'IP Version 6 Addressing Architecture'
>   <draft-ietf-6man-rfc4291bis-07.txt> as Internet Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2017-03-01. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting."

Nothing in the past really matters here, what matters is: "Is the bis draft
all set, did we fix all the things which must be fixed before this draft
becomes a real 'standard'?"

"no, I don't think we did" - randy (as strawman arguer)

Folk's frustrations are coming out, deep breath and think before 'send'
please... we're all really trying to do the right thing, yes?

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 24 Feb 2017 12:27:55 +0900

> And during those 11 years. Nobody implemented this rule specific to ::/3.

I can implement it today in some of our code if you like :-). But it seems
unlikely to make a difference, since the rule only applies to unicast
addresses in ::/3, and no such addresses have been released to the RIRs.
That in turn is unlikely to change until we run out of 2000::/3, and even
then we'll likely move on to allocating addresses out of 4000::/3 instead
of from ::/3.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 24 Feb 2017 12:31:55 +0900

On Fri, Feb 24, 2017 at 11:37 AM, Xing Li <[email-masked]> wrote:

> RFC6052. I suggest just provide pointers to those RFCs in rfc4291bis.
>

Yes, seems like those should be documented too. In fact, perhaps a general
exception for IPv6 addresses where the only non-zero bits in the IID are an
IPv4 address?

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 24 Feb 2017 12:34:32 +0900

On Fri, Feb 24, 2017 at 12:23 PM, Christopher Morrow <
[email-masked]> wrote:

> Nothing in the past really matters here, what matters is: "Is the bis
> draft all set, did we fix all the things which must be fixed before this
> draft becomes a real 'standard'?"
>

I don't think you can say nothing in the past matters here. We know that
there have been host implementations that relied on this guarantee, and we
have to consider that if we change the standard, those implementations will
become non-compliant.

---

From: Jared Mauch <[email-masked]>
Date: Thu, 23 Feb 2017 22:37:53 -0500

> On Feb 23, 2017, at 10:34 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Fri, Feb 24, 2017 at 12:23 PM, Christopher Morrow <[email-masked]> wrote:
> Nothing in the past really matters here, what matters is: "Is the bis draft all set, did we fix all the things which must be fixed before this draft becomes a real 'standard'?"
> 
> I don't think you can say nothing in the past matters here. We know that there have been host implementations that relied on this guarantee, and we have to consider that if we change the standard, those implementations will become non-compliant.

This has always been the case and was a big excuse given by Cisco back in the 1990s for not fixing the directed-broadcast problem.

For progress to occur sometimes a prior behavior will become invalid, if we can’t handle this then there’s no hope.  I don’t live in a world without hope.

- Jared

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 23 Feb 2017 22:41:43 -0500

gosh people are being literal today :)

> have to consider that if we change the standard, those implementations will

I don't think the proposed (now 160+ messages back) text really says: "FREE
FOR ALL< NO LIMITS!!! WEEE!" it says: "Hey, if you want to use /64 because
the application you are being placed into requires it (slac, blah and blah
and ilnp and blah - see rfc7k) then do that, else any other prefix length
works"

how's that not 'ok' for host folks? "Hi, my host is going to be in a slaac
world.. so /64 it is!"

---

From: Pierre Pfister <[email-masked]>
Date: Fri, 24 Feb 2017 07:58:46 +0100

> Le 24 févr. 2017 à 04:27, Lorenzo Colitti <[email-masked]> a écrit :
> 
> On Fri, Feb 24, 2017 at 7:43 AM, Pierre Pfister <[email-masked] <mailto:[email-masked]>> wrote:
> I can implement it today in some of our code if you like :-).

Good luck getting that upstreamed ! ;-)

> But it seems unlikely to make a difference, since the rule only applies to unicast addresses in ::/3, and no such addresses have been released to the RIRs. That in turn is unlikely to change until we run out of 2000::/3, and even then we'll likely move on to allocating addresses out of 4000::/3 instead of from ::/3.

So what you are saying is that all currently assigned unicast addresses are out of the ::/3 prefix. 
Meaning that, according to proposed standard, I should not be able to configure on-link prefixes of length different than 64 with currently assigned unicast addresses.
At least Linux, Windows, Apple, Cisco, and probably all mature IPv6 stacks, would let you configure prefixes of length different than 64.

- Pierre

---

From: Gert Doering <[email-masked]>
Date: Fri, 24 Feb 2017 08:55:41 +0100

Hi,

> have to consider that if we change the standard, those implementations will

Details, please.  Besides SLAAC not working (because not defined), which
implementations will not work with non-/64 network length?

You might know, but if you say "we know", it's not including myself (yet).

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Fri, 24 Feb 2017 08:59:40 +0100

Hi,

> And during those 11 years. Nobody implemented this rule specific to ::/3.

The point is not "specific rule for ::/3".  The point is that this is a
explicit rule for all that is *not* ::/3, with an exception(!) for ::/3.

... and still there are other RFCs that permit /126 and /127, so this
definitely needs rewording to match current reality.

Gert Doering
        -- NetMaster

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 24 Feb 2017 09:12:45 +0100

I wonder if anyone knows (or if there is an easy way to check, I doubt), if other STD documents have similar situations.

I mean, we define STDs, it takes long time to do so and meanwhile is still an RFC or even after a document is already an STD, there may be text sections that don’t reflect market reality, or some very specific exceptions (such as in this case /126-/127), that make sense (or not), but in any case, the STD is not being modified again and again.

I’m sure this happens in any kind of documents in other business and life fields, for example, there may be generic laws, and afterwards, the generic law is not modified for many many many years, but “exception rules” are created for those laws.

So, are we spending too much time in this and is not really necessary?

Can we live with the actual text with has been in the market, and working well, for “x” years?

Can we make too many (or few very important) changes in an RFC in the way to STD, or we need first to have those changes in an RFC for “x” years and “n” verified implementations, before we move to STD? If the answer is no, is the balance between living with the current text but moving to STD a better option than waiting for “x” years again?

Regards,
Jordi

-----Mensaje original-----
De: ietf <[email-masked]> en nombre de Gert Doering <[email-masked]>
Responder a: <[email-masked]>
Fecha: viernes, 24 de febrero de 2017, 8:59
Para: Pierre Pfister <[email-masked]>
CC: IPv6 Operations <[email-masked]>, Mark Smith <[email-masked]>, IETF <[email-masked]>
Asunto: Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets

    Hi,

    
    
    Gert Doering
            -- NetMaster

    

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Erik Kline <[email-masked]>
Date: Fri, 24 Feb 2017 18:04:30 +0900

On 24 February 2017 at 12:41, Christopher Morrow <[email-masked]>
wrote:

> I don't think the proposed (now 160+ messages back) text really says:
> "FREE FOR ALL< NO LIMITS!!! WEEE!" it says: "Hey, if you want to use /64
> because the application you are being placed into requires it (slac, blah
> and blah and ilnp and blah - see rfc7k) then do that, else any other prefix
> length works"
>

For manual assignment among consenting adults: as you like it.  (For all
prefixes longer than /64, the trailing 64bits would still end up being
unique; there is no real issue here.)

And I gather everyone agrees that at a minimum the /127 RFC and other
working-group-graduated documents should be suitably incorporated and
referenced.

Otherwise, this feels like another round of "why isn't IPv6 just 128bit
IPv4?"  IMHO having /64 as the logical unit of allocation to network leaves
is a very good thing.

---

From: Gert Doering <[email-masked]>
Date: Fri, 24 Feb 2017 10:33:08 +0100

Hi,

On Fri, Feb 24, 2017 at 06:04:30PM +0900, Erik Kline wrote:
> IMHO having /64 as the logical unit of allocation to network leaves
> is a very good thing.

Why, exactly, except "because it was decided to be that way, many years
ago"?

(Not that I have any plans to fight that particular windmill, but /64
never made sense to me, after all the more interesting aspects of 8+8
never happened, and thus, effectively, IPv6 today is "IPv4 with longer
addresses" as far as "hosts attaching to networks" and "routing" is
concerned...) 

Wasting half the address space and then having to start arguments on
the amount of subnets available to home users ("can we give them a 
/48, or will we run out?", "can we give ISPs enough space so they can
give all their users a /48, or do we need to make this a /56?", "how
much conservation is required by ISPs?") is major silliness - something
like a /96 would have served the aspect "more machines than you can
imagine per subnet" perfectly well.  SLAAC would have been a bit more
challenging, but "use the MAC address" was not *such* a good idea 
either.

Gert Doering
        -- NetMaster

---

From: Yoav Nir <[email-masked]>
Date: Fri, 24 Feb 2017 12:14:29 +0200

> On 24 Feb 2017, at 11:33, Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 
> imagine per subnet" perfectly well.

And you can see RFC 5739 on how a /64 subnet is required for each road warrior connected to a VPN.  You’d need a /56 or /48 to do what a /24 does in IPv4.

Yoav

---

From: Sander Steffann <[email-masked]>
Date: Fri, 24 Feb 2017 11:49:13 +0100

Hi,

> something like a /96 would have served the aspect "more machines than you can

Yeah, I wish we had chose something like that in the past as well :(

Cheers,
Sander

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 24 Feb 2017 14:13:13 +0100 (CET)

On Fri, 24 Feb 2017, Pierre Pfister wrote:

> At least Linux, Windows, Apple, Cisco, and probably all mature IPv6 
> stacks, would let you configure prefixes of length different than 64.

I just came back from PTO not reading IETF email for 5-6 weeks, and read 
up on this thread.

I just want to state my opinion that whatever text we come up with should 
reflect current operational reality, in that SLAAC A=1 only works on /64, 
and that people use all kinds of subnet sizes when manually configuring 
interfaces.

If current code doesn't treat 000::/3 in any special case, then documents 
should reflect this.

Mandating /64 only for any IPv6 use case doesn't reflect reality as I see 
it. I don't want to see A=1 /64 SLAAC requirement relaxed either.

I just want the -bis document to reflect what is currently in the field 
and we know works. Nothing more, nothing less.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 24 Feb 2017 15:09:36 +0100

Le 24/02/2017 à 07:58, Pierre Pfister a écrit :
>
>> Le 24 févr. 2017 à 04:27, Lorenzo Colitti <[email-masked]
>> <mailto:[email-masked]>> a écrit :
>>
>> On Fri, Feb 24, 2017 at 7:43 AM, Pierre Pfister
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> But it seems unlikely to make a difference, since the rule only
>> applies to unicast addresses in ::/3, and no such addresses have been
>> released to the RIRs. That in turn is unlikely to change until we run
>> out of 2000::/3, and even then we'll likely move on to allocating
>> addresses out of 4000::/3 instead of from ::/3.
>
> Meaning that, according to proposed standard, I should not be able to
> configure on-link prefixes of length different than 64 with currently
> assigned unicast addresses.

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?

Is that 64?  If yes then it's wrong.

Alex

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 24 Feb 2017 09:59:46 -0500

> the end user manually assigns an address on an interface without
I don't think this matters... 'end users' will in almost all cases just
attach and get connectivity. 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.

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

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 24 Feb 2017 10:04:11 -0500

On Fri, Feb 24, 2017 at 4:04 AM, Erik Kline <[email-masked]> wrote:

>> how's that not 'ok' for host folks? "Hi, my host is going to be in a
>> slaac world.. so /64 it is!"
>>
>
I agree.

> working-group-graduated documents should be suitably incorporated and
I think that's in the proposed text, yes... or easily is a list of
[this][that][theother]

> IPv4?"  IMHO having /64 as the logical unit of allocation to network leaves

For enduser deployment picking 'something' (/64 is perfectly fine) is
totally sane, and already in the proposed text. The sticking point isn't so
much: "ipv6 is ipv4 with  more bits" (which the network treats it as) but:
"hey, we know we allocate longer prefixes all the time for 'reasons' on
things that have bespoke config, let's not make that harder by letting
vendors/etc take shortcuts... acknowledge the fact that we really do have
interfaces with >/64 deployed.

I don't see how that damages network-ops folks, nor host-ops, nor
developers.

There is certainly a discussion for 'not this list' about networking
providers doing 'short sighted' things on their network with respect to
attached customers, but... that's not this document and not this discussion
and not this list (except as an opionion/editorial piece).

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 24 Feb 2017 16:48:43 +0100

Le 24/02/2017 à 15:59, Christopher Morrow a écrit :
>
>
> On Fri, Feb 24, 2017 at 9:09 AM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>>
>  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?

> 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?

That makes it mandatory that the CLI _requires_ a plen, right?  That CLI
should not allow silence for a plen parameter.

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.

Alex

---

From: heasley <[email-masked]>
Date: Fri, 24 Feb 2017 16:24:08 +0000

> Can we make too many (or few very important) changes in an RFC in the way to STD, or we need first to have those changes in an RFC for “x” years and “n” verified implementations, before we move to…

I prefer the document is fixed now; start the process of fixing classful
implementations now, rather than in x years - or please save operators from
those x+ years of pain.

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 24 Feb 2017 11:27:36 -0500

> 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.

> 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.

> 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.

> think it's wrong, there does not seem to be a commonly agreed 'by
correct, so.. be specific in your configuration effort please... which
again, means that the 'what is the default?" conversation is moot.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 24 Feb 2017 18:09:29 +0100

Le 24/02/2017 à 17:27, Christopher Morrow a écrit :
>
>
> On Fri, Feb 24, 2017 at 10:48 AM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]
> <mailto:[email-masked]>>> wrote:
>
>
> when the end user manually assigns an address on an interface
> without specifiying a prefixlen?
>
>
> 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.

> 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.

> That makes it mandatory that the CLI _requires_ a plen, right?  That
> CLI should not allow silence for a plen parameter.
>
>
> 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.

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.

Alex

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 24 Feb 2017 12:53:06 -0500

> 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.

> It's not an RFC that requires them to put 64 there.
ok

> the default to be 64.  This consideration is wrong.
yes, I agree with you here.

> validity of such assumption.  And that creates problems.

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

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 24 Feb 2017 19:08:38 +0100

Le 24/02/2017 à 18:53, Christopher Morrow a écrit :
>
>
> On Fri, Feb 24, 2017 at 12:09 PM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>         <mailto:[email-masked]>>
>         <mailto:[email-masked]>
>         <mailto:[email-masked]>>>> wrote:
>
>

That address is good, but how about the routing table?  Does it get an 
entry like 2001:700:4::/64?

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

:-)

Alex

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 24 Feb 2017 13:21:17 -0500

> entry like 2001:700:4::/64?
$ ifconfig em1
<snip>
          inet6 addr: 2001:700:4::1/128 Scope:Global
<snip>

and:
$ netstat -rnA inet6
Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use
If
2001:700:4::1/128              ::                         U    256 0     0
em1
<snip>
2001:700:4::1/128              ::                         Un   0   1     0
lo

that sure seems like i only got what I paid for.. on:
$ uname -r
3.13.0-92-generic

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 24 Feb 2017 19:36:11 +0100

Le 24/02/2017 à 19:21, Christopher Morrow a écrit :
>
>
> On Fri, Feb 24, 2017 at 1:08 PM, Alexandre Petrescu
>     That address is good, but how about the routing table?  Does it get
>     an entry like 2001:700:4::/64?
>
>
> $ ifconfig em1
> <snip>
> Destination                    Next Hop                   Flag Met Ref
> Use If
> 2001:700:4::1/128              ::                         U    256 0
> 0 em1
> <snip>
> 2001:700:4::1/128              ::                         Un   0   1
> 0 lo
>

Looks good in linux world.

Alex

---

From: Alexandre PETRESCU <[email-masked]>
Date: Fri, 24 Feb 2017 20:26:20 +0100

--
Alexandre Petrescu
[email-masked], tél 0169089223

> Looks good in linux world.

But, I would like to add that last time I checked (january 2015) the 
linux kernel complained in /var/log/messages  when receiving an RA 
containing a plen 65.  It called it "illegal" prefix length.
That RA was sent over usbnet.  There is no specification of 
IPv6-over-USB, there is no IID length requirement to be 64, because 
there is noo USB IEEE MAC address.

That was wrong at that time (call a 65 in RA "illegal"), I dont know 
whether it still the case.  I may check in some time in the following 
weeks, and this is the question I will follow: is the linux kernel 
complaining when receiving an RA with a plen 65 on usbnet?  If yes, then 
linux stilll has at least one problem with this 64.

What is sure is that there is still no IPv6-over-USB draft, so no IID 64 
on USB.

It's  a similar situation with cellular links instead of USB - no spec, 
but hidden assumptions about it being 64.  They are all wrong.

Alex

---

From: Gert Doering <[email-masked]>
Date: Fri, 24 Feb 2017 20:56:46 +0100

Hi,

> interfaces with >/64 deployed.

+1

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Fri, 24 Feb 2017 21:48:36 +0100

>interfaces with >/64 deployed.

I wonder if (in typical IPv4 fashion) we mix address configuration with
onlink prefixes.

There are three generic address configuration mechanisms, SLAAC, DHCP IA_NA,
and manual. Of these only SLAAC cares about the prefix length. And there
are good reasons to keep SLAAC at 64 bits.

(If would strongly suggest to not pick a random 32 bit IID, combine it
with a /96 and then hope that duplicate addresses detection in all cases
will safe the day. So for longer prefixes, use DHCP or manual configuration.)

For DHCP and manual configuration, an address is just that, an address.
So in that case, the prefix length actually refers to the length of the
onlink prefix.

Note that RFC 4861 (Neighbor Discovery) already specifies that an onlink
prefix can have arbitrary length. 

So it safe to assume that hosts can support arbitrary length onlink
prefixes. Otherwise those host implementations are already broken.

DHCP doesn't have a prefix length, so that's not an issue.

So that leaves hosts that mistakenly combine manual address configuration
with implicit onlink prefix configuration and an arbitrary restriction
on the prefix length. It is safe to declare those hosts broken.