Presentation is loading. Please wait.

Presentation is loading. Please wait.

Requirements (and Other Considerations) for NAT-PT Replacement from RFC 4966 IETF70 Vancouver v6ops W.G. December 6, 2007 Elwyn Davies.

Similar presentations


Presentation on theme: "Requirements (and Other Considerations) for NAT-PT Replacement from RFC 4966 IETF70 Vancouver v6ops W.G. December 6, 2007 Elwyn Davies."— Presentation transcript:

1 Requirements (and Other Considerations) for NAT-PT Replacement from RFC 4966 IETF70 Vancouver v6ops W.G. December 6, 2007 Elwyn Davies

2 6 Decmeber 2007v6ops NAT-PTbis Requirements from RFC 4966 2 RFC 4966 RFC 4966 consigned original NAT-PT (RFC 2766) to Historic status –Contains an analysis of failings of NAT-PT Requirements and Issues for a replacement derived from analysis Discussion of some architectural trade offs

3 6 Decmeber 2007v6ops NAT-PTbis Requirements from RFC 4966 3 Interactions with DNS DNS ALG is major problem of NAT-PT –Synthesized AAAA responses violate expected global validity of DNS response Possible approaches: –Translate A records in host Translating DNS resolver - issue with applications that have own resolvers A host (stack) modification R1: Any modifications to DNS responses associated with translation MUST NOT violate standard DNS semantics

4 6 Decmeber 2007v6ops NAT-PTbis Requirements from RFC 4966 4 Host/Application Awareness An architectural trade-off RFC 2766 aims for transparency and autonomous operation New solution options (combinations possible): –Stick with transparency –Allow host stack awareness of translation IPv6 side only a.s. - IPv4 changes unfeasible –Require host stack awareness –Allow application awareness –Require application awareness Awareness is not a binary value

5 6 Decmeber 2007v6ops NAT-PTbis Requirements from RFC 4966 5 Awareness Might Enable... Using optimum network (native IPv6 vs translation) when there is a choice Using IPv6 capabilities when they are available but not when translating –Unawareness promotes Lowest Common Denominator situation and IPv6 stasis Control connection from host to gateway –Dynamic authentication and authorization of gateways –Reduced need for NAT(-PT) traversal help

6 6 Decmeber 2007v6ops NAT-PTbis Requirements from RFC 4966 6 Awareness cons Deployability –if host and/or applications are REQUIRED More work in converting applications Potential need to modify multiple DNS resolvers in one node (see above) Some RFC 2766 issues can be fixed up with minimal 'awareness' –e.g., better address selection algorithm

7 6 Decmeber 2007v6ops NAT-PTbis Requirements from RFC 4966 7 Referrals Is there a way to provide a universal ID that can work across IPv4 and IPv6? –Existence proof: See SHANTI proposal

8 6 Decmeber 2007v6ops NAT-PTbis Requirements from RFC 4966 8 Multicast RFC 2766 won't translate multicast Is this a big problem? Proposals believed to be in the pipeline

9 6 Decmeber 2007v6ops NAT-PTbis Requirements from RFC 4966 9 Mobile IP RFC 2766 breaks Mobile IPv6 How important is this? Co-locating NAT-PT and Home Gateway might help? –Avoids two rendezvous points

10 6 Decmeber 2007v6ops NAT-PTbis Requirements from RFC 4966 10 Scalability Support potentially multiple gateways per 'island' –Dynamic selection of gateway Reduce single point of failure vulnerability Distibute traffic load


Download ppt "Requirements (and Other Considerations) for NAT-PT Replacement from RFC 4966 IETF70 Vancouver v6ops W.G. December 6, 2007 Elwyn Davies."

Similar presentations


Ads by Google