Re: [v6ops] I-D Action: draft-horley-v6ops-lab-00.txt

[Ed Horley <[e-mail]>]

Dale,
Comments inline below with [ETH] starting my comments

On Mon, Jun 14, 2021 at 12:15 PM Dale W. Carder <[e-mail]> wrote:

> Thus spake Brian E Carpenter ([e-mail]) on Fri, Jun
> 11, 2021 at 10:22:51AM +1200:
> > My concern about this draft is that it intentionally creates ambiguous
> address space, something we have very carefully avoided since the beginning
> of IPv6.
>
> I'm not sure I worry as much about ambiguous as having more prefixes
> be marked "special", some of the implications of which seem may be at
> the heart of this proposal.
>
> In draft-horley-v6ops-lab-00.txt,
>
> "For instance, designing labs utilizing ULA fc00::/7
>    [RFC4193] is problematic due to the random global ID requirement
>    preventing hierarchical network prefix design possibilities."
>
> Have the authors considered updating 4193?  Is the randomness the issue,
> or is the resultant /48 the issue?  (of course, one could utilize
> multiple random /48's as I think has been pointed out)
>

[ETH] RFC 4193 section 3.2 is pretty clear.
"  The allocation of Global IDs is pseudo-random [RANDOM].  They MUST
   NOT be assigned sequentially or with well-known numbers.  This is to
   ensure that there is not any relationship between allocations and to
   help clarify that these prefixes are not intended to be routed
   globally.  Specifically, these prefixes are not designed to
   aggregate."

The authors of RFC 4193 felt the pseudo-random property important enough
aspect of ULA to make it a "MUST NOT" use without it. In addition, because
of that specific requirement, there are operational implementations of ULA
that have this REQUIREMENT already built into it. For us to come back and
change that fundamental characteristic now would likely cause more pain and
confusion. It is far simplier to assign the use of a currently deprecated
address space (we are proposing 200::/7, but I am certainly open to hearing
if others have a better recommendation) and move forward without changing a
fundamental attribute of ULA.


>
> "Further, default address selection behavior [RFC6724] by end nodes
>    may result in a depreferencing of such addresses and prevent lab
>    deployments from accurately modeling their desired non-lab
>    equivalents."
>
> And this is the implication of having prefixes marked as special.  The
> default behavior (which is only a SHOULD, i think) is not configurable or
> at least not in a sane manner on a variety of platforms.  Presumably the
> closed ecosystem devices (handhelds, particularly) have a goal of
> minimizing user complaints and implement the table as specified, notably
> with ULA at a lower precedence than GUA.  Would your document also need
> to update 6724's table?  If I were a closed ecosystem vendor, once I
> found out that $new_prefix gets assigned for lab use, I would probably
> be inclined to move it fc00::/7 now that it becomes "special" rather
> than as a stock GUA.
>
> [ETH] If we adopt something other than ULA (fc00::/7), Site-Local
(fec0::/10), 6bone (3ffe::/16) then there is nothing that needs to be done
to RFC 6724. I would prefer to not update or touch RFC 6724 at all. The
current prefix policy table in 6724 is:

      Prefix        Precedence Label
      ::1/128               50     0
      ::/0                  40     1
      ::ffff:0:0/96         35     4
      2002::/16             30     2
      2001::/32              5     5
      fc00::/7               3    13
      ::/96                  1     3
      fec0::/10              1    11
      3ffe::/16              1    12


Everything below (less than Precedence 35 for ::ffff:0:0/96) is
functionally useless on an dual-stack network. The majority of lab
implementations, we believe, will utilize a dual-stack approach and if ULA,
Site-Local or even 6bone address space is used for lab purposes, you will
NOT have a realistic set of host OS behaviors compared to when you actually
deploy with GUA. To state it simply, ULA is not a functional solution for
the lab prefix without fundamentally changing both RFC 4193 (see comments
above about why that is a poor idea) and also RFC 6724.

To avoid this very simple problem, we felt the solution was to just assign
GUA space that is for a lab function, mark it as "MUST" be filtered at the
Internet edge, have IANA reserve it for that purpose and the problem is
solved. We picked, as I mentioned above, 200::/7 because it is reusing a
large prefix allocation that is currently marked as deprecated by IANA (not
useable). So we are bringing life back to an address space, that will still
work for the lab functional requirement, and not allocating something that
could break up the larger address prefixes that could be assigned to any of
the RIRs. We saw this as a win/win/win. We don't have to change RFC's, we
don't need to change software OS code, we are recycling/reusing without
breaking out additional address space from the useable GUA ranges not
allocated yet.

Dale
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>


-- 
Ed Horley
[e-mail] | [phone]
Advancing Cloud, IoT, and Security with IPv6
https://hexabuild.io
And check out the IPv6 Buzz Podcast at
https://packetpushers.net/series/ipv6-buzz/