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

[Michael Richardson <[e-mail]>]

Wow, it's a really long thread full of really deep interpretation required.
{I wish we knew if this was 6man or v6ops...  I think that some of our
problem is that we don't know}

I think that Ted said it best:

} The question is not what possible scenarios are there, but what scenarios
} do we want to address with default behavior versus what scenarios can we
} only address with managed behavior. So e.g. not using longest-match for
} ULAs with different global identifiers sounds like a good default behavior,
} but obviously will break in some scenarios; in these scenarios, clearly we
} need support for configuring source address selection (which we already
} know how to do). Preferring GUA source address over ULA makes sense by
} default, I think, even though it is not always going to be the right thing
} to do.

Given that the original poster was talking about re-ordering rules, as well
as adding new rules to gai.conf, etc.  I would add to the question:

  *are we missing a protocol that would allow the network to express local
  preferences better*?

(I'm not saying that this is a new RA extension, but it could be.  Maybe
there is an existing thing that I'm not familiar with, or maybe does not have
widespread implementation)

I'd like to say that SHIM6 would have solves most of the problems.
It's possible/likely that while it's written "SHIM6", it's pronounced "QUIC"

In any case, it seems that even if the answer is QUIC, that we need an easier
to use API.   I know that there have been experiments with keep congestion
information across flows.  That this seems easier if it's all in the kernel,
but AFAIK, none of the experiments have made it out.   I mention this,
because that's among the new APIs that are needed.

If we can't solve the source address selection problem, and get it widely
deployed, we will wind up with NPT, and that would be very sad.
It seems a tragedy of the commons here.


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