Re: [Anima] Erik Kline's Discuss on draft-ietf-anima-autonomic-control-plane-28: (with DISCUSS and COMMENT)

[Erik Kline <[e-mail]>]

Toerless,

Thanks for taking the time to go through all this.  Generally LGTM, but I
would like to iterate on the ULA text (nothing major).


> > [ section 2 ]
> >
> > * "It is the approximate IPv6 counterpart of the IPv4 private address
> >   ([RFC1918])."
> >
> >   I understand the intent but I don't think this statement is complete. I
> >   think we shouldn't let this sentence out into the wild as is since it
> could
> >   be read without any context nor even any pretense of interest in
> nuance.
> >
> >   May I suggest:
> >
> >   "It is often thought of as the approximate IPv6 counterpart of the IPv4
> >   private address space ([RFC1918]), though it is in fact meaningfully
> >   different in important and subtle ways [and upon which this document
> relies]."
>
> Thanks for not trying to talk me out of the comparison, which i
> successfully
> used to explain ULA to many customers. Your proposal is a bit too verbose
> for
> the terminoloy section, so it's now:
>
> It is often thought of as the approximate IPv6 counterpart of the IPv4
> private address (<xref target="RFC1918" format="default"/>). There are
> important differences though that are beneficial for and exploited by the
> ACP, such as the ULA Global ID prefix, which are the first 48-bits of a ULA
> address. In this document it is abbreviated as "ULA prefix".
>

It's a statement of fact that this is how people unfamiliar with this space
view this space.  It's apparently also a statement of fact that people are
still actively being told this.  ;-)

But I still think it's not quite right.  For one, the real counterpart to
1918 in IPv6 is the deprecated site-local prefix.  Also, to say it's "often
thought of" in an IETF document implies more IETF folks think of this way,
when in reality I'm not sure that's the case.

If you really want to leave this notion in (removing the sentence
altogether is good by me), perhaps we can wordsmith it a bit more.  If I
may propose:

OLD:

   ULA: (Global ID prefix)  A "Unique Local Address" (ULA) is an IPv6
      address in the block fc00::/7, defined in [RFC4193].  It is often
      thought of as the approximate IPv6 counterpart of the IPv4 private
      address ([RFC1918]).  There are important differences though that
      are beneficial for and exploited by the ACP, such as the ULA
      Global ID prefix, which are the first 48-bits of a ULA address.
      In this document it is abbreviated as "ULA prefix".

NEW:

   ULA: (Global ID prefix)  A "Unique Local Address" (ULA) is an IPv6
      address in the block fc00::/7, defined in [RFC4193].  Sometimes
      thought of as the approximate IPv6 counterpart of the IPv4 private
      address ([RFC1918]), there are important differences that are
      beneficial for and exploited by the ACP.  In this document, the
      "ULA prefix" refers to Locally Assigned Global ID prefixes, which
      are the first 48-bits of the ULA address [RFC4193 section 3.2.1].

(I didn't think it was worth trying to get into the fc00::/8 vs fd00::/8
distinction in this glossary text.)

> [ section 8.1.3 ]
> >
> > * Why is an RIO for ::/0 with a lifetime of 0 required?  Doesn't it
> suffice
> >   it set the default router lifetime to 0?  Separately, are all nodes
> required
> >   to be Type C?
>
> Check the new text, i hope it explains everything.
>
> Yes, type A and B do not support per-prefix auto selection of router,
> The lifetime of 0 is used so only Type C hosts will invalidate the
> default route for the ACP edge node, but not Type A/B hosts. Maybe there
> is another parameter combination that achieves this goal, but this was
> the easiest for me to assess/describe.
>

This looks better, thank you.

To be honest, I don't know what the point of Type A/B hosts is anymore (and
if it were possible to declare these anima deployments greenfield I would
recommend saying the default router lifetime MUST be zero in the RA header
to force clients to use a stack that works -- but that's just me).