Re: [v6ops] ULA precedence [Thoughts about wider operational input]

[Michael Richardson <[e-mail]>]

    fred> You might look at section 3 of RFC 4193, and specifically at the global ID
    fred> mentioned in section 3.2. I'm looking at the first 48 bits of the address
    fred> and calling it a routing prefix. Let me put the question back to you:
    fred> starting from RFC 4193, what other prefix would be under consideration, and
    fred> why would it be under consideration?

Ed Horley <[e-mail]> wrote:
    > Yes, I am familiar with section 3.2 - my question is because several on
    > this mailing list in the past have said to ignore the stated pseudo-random
    > requirement in that section and not to follow this section which states
    > "Specifically, these prefixes are not designed to aggregate." Obviously, if
    > you don't follow that then the question comes back to are we still assuming
    > a /48? Or do we mean something different when we say "same prefix"? Is that
    > defaulting to just the overall ULA prefix itself because people are
    > designing networks starting at fd01::/32, fd02::/32, fd03::/32...
    > fdff::/32, etc. which I completely understand is not how 4193 says to do
    > it, but it is happening, so we need to be thinking about it perhaps? Just
    > curious if anyone else is seeing this behavior with their customers at
    > all?

I'm understanding the question to be:

For instance, if two enterprises with internal ULA-R's merged, then they
might prefer that ULA1 was used as a source address even when speaking to
ULA2, rather than a GUA.

(Should they renumber into a single ULA?  Probably, but this is a place where
IPv6 and ULAs are supposed to be a win)

If I have fd01:abcd:1234:4567::A/64 as an address, one can see how a system
could be automatically configured to prefer that address when talking to
destinations like fd01:abcd:1234::/48 ("ULA1")

I don't know how it would know to use fd01:abcd:1234:4567::A/64 when talking
to fd02:fedc:8765::/48 ("ULA2").  Really, this comes back to the general
source address selection problem with multi-homing, which homenet tried to solve.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide