1 / 6

6to4 Provider Managed Tunnels draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02

6to4 Provider Managed Tunnels draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02. Victor Kuarsingh, Rogers Communications Inc. Level Set. Native IPv6 is still the best option for IPv6 services Native IPv6 is “NOT” available or deployable everywhere right now (working on that)

livana
Télécharger la présentation

6to4 Provider Managed Tunnels draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 6to4 Provider Managed Tunnelsdraft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02 Victor Kuarsingh, Rogers Communications Inc

  2. Level Set • Native IPv6 is still the best option for IPv6 services • Native IPv6 is “NOT” available or deployable everywhere right now (working on that) • Vendor Equipment/Software (Network Side) • CPE (install base, buggy IPv6 code) • Transition Technologies often requires CPE • 6to4 is out there • Hosts, gateways/CPEs (in use) • 6to4 is challenging for providers who have CGNs in place or soon will have (IPv4 depletion) • IPv6 connectivity does not solve the entire IPv4 challenges

  3. Document Scope (Adjustments) • Original scope of document included: • Unmanaged CPE with 6to4 Turned(Challenged connectivity) • CPEs with 6to4 Turned on Behind CGN • Draft now concentrates on main use case of 6to4 behind CGN • Where Global IPv4 addresses are Used (Legitimate and less legitimate use cases) • Transparency not an issue here (broken anyways) • Can still technically be used for non-CGN use case (Not Recommended) • No direct participation required from external networks

  4. Technical Points (Brief) • 6to4-PMT operates northbound of 6to4 (RFC3068) clients • Combines normal 6to4 with NAT66 operation • No Checksum Neutral mappings / devcode utilized RFC3022 Checksum Adjustment • Translates 2002: ADDR to 2001:db8 (Provider Assigned) ADDR • Low Cost • updates current 6to4 relays if Linux based as example – in place upgrade • If used in non-CGN model, may help alleviate challenges related to neighboring networks • draft-carpenter-v6ops-6to4-teredo-advisory (typo in draft reference)

  5. Testing Results (PreProd Environment) • The concept works as expected (RUNNING CODE, free to use - open) • Client to Server options operate well • Able to “undo” challenges related to 6to4 behind CGN • Does not fix peer-peer 6to4 endpoint communication (broken anyway) – unless both sides do NAT • Runs on same system as normal 6to4, • where only policy triggered endpoints are subject to translation (provider dependent) • Some Considerations • Some peer to peer considerations (PMT to 6to4) • Referrals to local 2002:: from PMT subject host • Transparency if used in general (non-CGN) environment

  6. Next Steps • WG Document? • If yes then…. • WGLC • If no then… • Chairs

More Related