On 24 jul 2008, at 22:45, Dave Thaler wrote:
(Don't forget that until the EDNS0 SAS option is supported, you
really
don't want to give hosts with dual stack reachability synthetic AAAA
records.)
Sounds like the case you're talking about is a multi-homed client.
That was what I have in mind with regard to the failover part that I
discussed before, but this has nothing to do with the text that you
quoted...
Since above we're talking about v6-only networks, but hosts with
dual stack reachability.
I'm assuming it would be possible that all hosts share the same IPv6
connectivity, but some also have IPv4 and others don't. Perhaps this
isn't a very likely scenario; the easiest way to make this happen
would be to give IPv4 over tunnels to some hosts but not others,
presumably this wouldn't be a common configuration.
Then again, as an ISP you never know what your customers do on their
networks, so it may or may not be safe to provide them with synthetic
AAAA records.
We need to pick one. If people then choose to implement
administrative
overrides, that's their choice, but that means that the burden to
make
it work is on those implementers/operators.
I think it also depends on the scenario. If you're putting NAT64
close to the client (i.e. matching the default route is ok) then
you can use a well-known range.
Right. If we want to put it far away from the client = make it a
service that can be provided by a third party over the internet, we
need some kind of authenication, which isn't in there now.
If you're putting NAT64 across the internet from the hosts that
will use IPv6 (e.g. closer to IPv4-only servers, at the edge of
a v4-only network), then you need a routable prefix.
That, too, yes.
That's why I want pictures in the draft to see which scenarios you're
targeting.
I guess I'll have to make some. :-)
A few of us are presenting operational considerations for NAT64 etc in
the ops area session.
Well, for things to work well, we pretty much need updates: the EDNS0
option if we go with arbitrary translator prefixes, allowing v4mapped
addresses on the wire if we go with v4mapped.
I'm not yet convinced that we need updates to existing dual stack
nodes.
You do if you want to run DNSSEC or IPsec over NAT64, and maybe if you
want to have fast failover when a NAT64 fails.
I work for a company that does patches over the Internet. The bar
for pushing patches automatically to existing hosts is very high
(basically security fixes only). And if it's not automatic, just
available, then you have to assume that most hosts won't have it.
Back in the day we gave users CDs with software they had to install to
connect to the internet when they signed up for internet access. I
don't think it's unreasonable to expect users who will be getting
IPv6+NAT64 connectivity to install an OS patch.
Hence we do need to optimize for unmodified hosts in my view,
at least for the short term.
How short?
For informational purposes, it might be interesting to
repeat your experiments using the range ::/96
Sure, as long as we're testing anyway. Not sure what the advantages
of
using this range would be, though.
Marcelo already answered this... existing hosts sort them after
native IPv6 addresses.
Hm, despite my feature requests not all OSes that I use support the
RFC 3484 policy table. (I guess if they can't even acknowledge, let
alone fix, the fact that IPv6 packets larger than 2k can't be
transmitted successfully over firewire, which leads to real-world
breakage for normal use cases, then this one must be quite low on the
list. I wasn't happy when another OS that I use simply removed
firewire networking but at least that way users don't run into bizarre
problems. On the remaining OSes that I use it never worked so at least
there are no expectations.)
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
