Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

[Lorenzo Colitti <[e-mail]>]

If the prefix length changes away from 64 bits it will be a major change
that will affect this document in many ways.

I'd leave as is. It's definitely useful for the uninitiated reader to know
that currently the only prefix size that is valid and accepted by
implementations is 64.

On Sat, Aug 19, 2017 at 5:05 AM, Fred Baker <[e-mail]>
wrote:

> Hat off...
>
> Why not simply say "a prefix"? We are perpetually wrapped around an axle
> with the prefix length, but reading this 20 years from now (which is the
> perspective one should take in writing an RFC - what will it mean when it's
> history?) I don't see why they would worry about the exact length someone
> wanted to assign within their own boundaries.
>
> > On Aug 18, 2017, at 12:46 PM, Alexandre Petrescu <
> [e-mail]> wrote:
> >
> >
> >
> > Le 18/08/2017 à 20:46, 神明達哉 a écrit :
> >> At Fri, 18 Aug 2017 20:24:50 +0200, Alexandre Petrescu <
> [e-mail]> wrote:
> > [...]
> >> In any event, my point below was that as long as this draft talks about
> a live practice using today's standards, it doesn't make sense
> >> to discuss whether the choice in those standards (i.e., 64-bit IID) is
> good/bad in that context.
> >
> > I agree.
> >
> > Maybe the 64bit IID is not a matter of this draft, since this draft is
> > about prefixes.
> >
> > The IID length should be discussed in the other WG.
> >
> > Here, still it makes sense to allow for prefixes shorter than 64 (i.e.
> > unique /63 prefix per Host, such that it can further grow the network by
> > becoming a Router).
> >
> > The draft says:
> >> a Unique IPv6 prefix (currently a /64 prefix) and some flags.
> >
> > That "currently a /64" sounds as a hardcoded value.
> >
> > It should be something like: "a variable length whose value could be /56
> for example; it could also be /64".
> >
> > Alex
> >
> >> If we want to have that discussion that should take place somewhere
> else (and not even appropriate for v6ops in general, since changing that
> would be most likely to involve a protocol change).  Especially so when
> such a discussion always leads to a non-productive
> >> repetition of stating different opinions.
> >>>> I'm not sure why we are talking about our favorite topic of 64-bit
> (or not) IIDs here:-)  This thread is even more inappropriate for that
> topic than 4291bis (even where it's out
> >>>> of scope as it's not feasible to change that as part of promoting
> >>>> it to IS).  People who want to discuss the endless IID length
> >>>> debate should really aware of the scope of the topic.
> >> -- JINMEI, Tatuya
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>