Dear Brian, all, Please see inline.
Cheers, Med -----Message d'origine----- De : [email protected] [mailto:[email protected]] De la part de Brian E Carpenter Envoyé : mardi 10 novembre 2009 01:35 À : james woodyatt Cc : NAT66 HappyFunBall; [email protected] Objet : Re: [nat66] Necessity for NAT remains in IPv6 On 2009-11-10 13:03, james woodyatt wrote: > On Nov 9, 2009, at 15:15, Brian E Carpenter wrote: >> On 2009-11-10 04:11, Chris Engel wrote: >>> 2) NAT serves to abstract internal hardware that provides services from the >>> external advertisement of those services. Making it very easy and flexible >>> to distribute and redistribute the provision of those services among your >>> internal hardware. >> I though we covered that, though not in those words. Certainly topology >> hiding, one of the areas we discuss at some length,is a big part of that >> (and is part of the gap analysis, so we tend to agree that is a weaker area). >> >> Also of course ULAs are specifically designed to "abstract internal hardware >> that provides services from the external advertisement". > > Actually, I think Mr. Engels wants port-translating IPv6/NAT, expressly for > making *surjective* mappings from unique local port/addresses to public > port/addresses. He doesn't seem to want this for topology hiding purposes, > so much as for achieving high service availability. > Ah, you mean the utilisation of NAT covered by US Patent 5371852? Yes, I agree that this is missing. My opinion is that since IPv6 offers the ability to synthesise an effectively infinite number of virtual addresses for virtual servers within an array of physical servers, we don't need to play NAPT games to achieve this. Yes, this missing from 4864. Med: We have identified a use case in which such NAPT66 functionality may be required to avoid introducing NAT64 devices in the core network (see http://tools.ietf.org/html/draft-boucadair-behave-ipv6-portrange-04#section-6.6.3). Except the need to avoid stateful devices (which means: CAPEX/OPEX constraints, maintenance issues, constraint on session establishment and need to embed updated ALGs, routing optimisation, robustness, etc.) in the network and the forthcoming IPv4 address exhaustion, I don't have other arguments to justify that this would be a viable use case. Cheers, Med ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ******************************** _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
