On Apr 7, 2009, at 12:18, Keith Moore wrote:
james woodyatt wrote:
The latest message I received concluded with these paragraphs:
In summary, I agree that your proposal will work, if both B2B
partners
agree to advertise their FC00:: routes to each other via the private
link. But there is some risk to the business from the additional
routes in the route table. Also some extra complexity from the
additional static configuration (enabling use of the fc00:: subnet
on
the host, and possibly the fc00::/7 -> route if that can't be put
in a
router advertisement).
Just curious - assuming that ULAs should be used at all (and it's not
immediately clear that they should), why wouldn't an RA containing the
ULA prefix suffice to enable use of the subnet on each host?
I'm still trying to socialize the idea that router advertisements may
carry prefix information options with the A bit cleared and that this
will signal hosts not to auto-configure any addresses with the prefix.
I'm expecting this fact to land in persistent memory at some point so
it will not need any further repetition. Cross your fingers with me.
To me it seems like more problems are likely to result from use of
ULAs
as secondary prefixes, than from use of PA or PI global addresses. In
particular, applications have to know whether to use a ULA or P*
address
as a source and/or destination address, and default address selection
rules don't always do the right thing. So you might have to
statically
configure each app (because the "right thing" will vary from one app
to
the next) but not each host.
As I wrote to you privately, I'm not sure I see why they feel the need
to use ULAs at all. It might just be that they read draft-baker-v6ops-
b2b-private-routing, and now they're assuming that's Fred's way is the
best current practice. I'm trying to find out.
I don't consider the operational impacts to achieve "no IPv6 NAT
purity" worth it. IPv6 to IPv6 NAT is an important tool in the
network engineer's toolbox.
Reading this, it's difficult to not be reminded of Maslow's hammer
that
makes everything look like a nail.
I prefer to think that when all you have is a hammer, then everything
begins to look like a trombone player.
Still, it's important to understand this case better. Either we
need to
address it in an update to RFC 4864, or we need to make sure that IPv6
NAT satisfies this case. (or maybe both, on the assumption that
there's
too much mindshare behind NAT to expect network engineers to give it
up
as a condition of IPv6 transition.... but we can hope that they'll
learn
eventually to do without it.)
I'm trying to pry a better description of this use-case out of the
experts with whom I have some contact. I recommend that others on
this list who have similar contacts begin availing themselves now. We
need to figure out what these people are doing that has all these
equipment vendors spinning up to sell them NAT66 boxes whether IETF
standardizes it or not.
--
james woodyatt <[email protected]>
member of technical staff, communications engineering
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
