Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Address

On 23 February 2017 at 15:05, Lorenzo Colitti <lorenzo(_at_)google(_dot_)com> 
wrote:

> On Thu, Feb 23, 2017 at 1:28 PM, Randy Bush <randy(_at_)psg(_dot_)com> wrote:
>
> > > the IETF and 6man absolutely have the ability to change the standard,
> > > but it should follow the proper process: write a draft, get consensus,
> > that is the process we are currently in.  but there seems to be serious
> > disagreement over the draft.
> AIUI the goal of the process is to reclassify the current specification.
> That severely restricts the types of changes that are possible. That is the
> basis on which this document gained WG consensus and reached IETF last call.
>
> If we want to say that we're no longer reclassifying the current
> specification but are instead opening the door to bigger changes, then the
> document should go back to the WG for further work because the existing WG
> consensus was based on the stated goal of reclassifying the document.
I agree with the procedural concerns here.  Among other things, if we make
substantial changes it's hard to claim we have experience running the new
thing we've documented.

I tend to think of IID concept's primary use as: if I have the IID
::dead:beef/64 then for every new /64 PIO that's announced *I* can
reasonably expect to lay claim to prefix1::dead:beef/64,
prefix2::dead:beef/64, and so on.  (Support for this mode operations,
SLAAC, is a MUST.)

I don't personally find any major conflict when considering static and
stateful addressing.  For example, if there are 2 prefixes on a link, and
the administrators are using static addressing then prefix1::cafe and
prefix2::cafe do not in any way have to belong to the same interface on the
same host. ... at least as far as I understand it.  If prefix1 and prefix2
are each longer than /64 then each 64bit IID would still be unique--no
problems.  But if each were <=64 then it's just violating a recommendation
in the first paragraph of 2.4.1--not a big deal for the administrator that
wants to run that way.

I'm not sure if this adds anything useful to the discussion, though.
-Erik

smime.p7s
Description: S/MIME Cryptographic Signature