On 2008-07-25 08:45, Dave Thaler wrote: >> -----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.
I agree with Iljitsch to the extent that this should be a MUST implement. > > 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. Indeed, but this is clearly more complex, will need configuration or discovery, and I think should probably be MAY implement. > > 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. I hope not, but possibly that has to sy: unless they are deployed on a mixed network along with IPv6-only stacks. At the least, they will need to receive different configuration in that case. Brian > >> 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
