Basically that is what I was thinking, not sure could say problem solved as would still be using big nat boxes, but if we are going to 'have' to have nat, why not in a form that encourages adoption of IPv6?
Having have said that, from someone else's comment would have to agree with them about using ipv4 nat dual stacked with ipv6 instead. Would likely be more realistic due to how little time have before ipv6 exhaustion and end systems that need additional configuration to enable ipv6 (and I know how much support people hate having to help end users setup things they don't understand... like email settings, they at least know what e-mail is and why they are setting it up, how many don't know what IP is and would just get frustrated at doing something they don't understand why?) -----Original Message----- From: Brandon Galbraith [mailto:brandon.galbra...@gmail.com] Sent: Wednesday, 18 February 2009 1:14 PM To: Nathan Ward; nanog list Subject: Re: IPv6 Confusion So we deploy v6 addresses to clients, and save the remaining v4 addresses for servers. Problem solved? -brandon On 2/17/09, Nathan Ward <na...@daork.net> wrote: > On 18/02/2009, at 3:23 PM, Randy Bush wrote: > >>> I find it a shame that NAT-PT has become depreciated >> >> the ietf has recanted and is hurriedly trying to get this back on >> track. of course, to save face, the name has to be changed. > > Sort of - except it is only for IPv6 "clients" to connect to named > IPv4 "servers". NAT-PT allowed for the opposite direction, IPv4 > "clients" connecting to IPv6 "servers" - NAT64 does not. > > The server must have an A record in DNS, and the client must use that > name to connect to - just like NAT-PT. > > -- > Nathan Ward > > > -- Sent from my mobile device Brandon Galbraith Voice: 630.400.6992 Email: brandon.galbra...@gmail.com
