> -----Original Message----- > From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 24, 2008 1:13 AM > To: Dave Thaler > Cc: marcelo bagnulo braun; [email protected]; Dan Wing; Jari Arkko; > Philip Matthews; Brian E Carpenter; Alberto García > Subject: Re: practical issues with using v4-mapped addresses for nat64 > > On 23 jul 2008, at 23:05, Dave Thaler wrote: > > > People that deploy v6-only networks will just hand out a DNS64 server > > address as the IPv6 address all clients should use for their DNS > > server. > > (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. Since above we're talking about v6-only networks, but hosts with dual stack reachability. > > Hence Brian Carpenter's suggestion to default to v4mapped but allow > > configuration to support some other prefix, which sounds reasonable. > > No, this is a bad solution, because it requires that we address the > limitations of both options, and ISPs may opt for one while end-user > equipment only supports the other. > > 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. 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's why I want pictures in the draft to see which scenarios you're targeting. > > However, I would still argue strongly that we should not require > > changes > > to existing dual-stack nodes in order to deploy something that > doesn't > > break apps. (Requiring changes in IPv6-only nodes is much less bad, > > although still undesirable.) > > 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. > Fortunately, all systems that we can assume to run in IPv6-only > environments in the future can download patches over the internet, so > this isn't a show stopper. > > At the same time, it is of course very helpful to make sure that > unupdated systems can work reasonably well. But I don't think we > should optimize for this at the expense of having a solution that > works well on updated hosts. 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. Hence we do need to optimize for unmodified hosts in my view, at least for the short term. > > 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. -Dave _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
