案６IPv6 on FLETS Hikari: a way forward?
Lorenzo Colitti
Erik Kline

Google Confidential and Proprietary

Disclaimers● The following is to the best of our current knowledge● These are our personal opinions only and do not necessarily reflect
the opinions of Google● We offer these opinions in the hope that they will help the industry
transition to IPv6, because we believe that widespread deploymentof high-quality IPv6 Internet access is key to the long-term health ofthe Internet● Google is not a player in the Japanese ISP market● Now, with that out of the way...

Google Confidential and Proprietary

Background● World IPv6 Launch○○○"Fallback" problem caused widespread AAAA filtering
Risk: Japan takes its own path as the rest of the world embraces IPv6
Only solution is wide deployment of IPv6 Internet access● IPv6 support provided by FLETS光○○NGN: 案２ (PPPoE+NAT66), 案４ (native IPoE+source routing)
B-FLETS: currently no options● ISP uptake of IPv6 on FLETS 光 is very low (~0.1%)○

Suggests options are unattractive● Easiest path might be:○○

Start from NGN (there are technical options already)Start from existing options and make as few changes as possible

Google Confidential and ProprietaryAssumptions● Based on our understanding:● IPv6 IPoE lower infrastructure cost○○○

No PPP concentrators
No L2TP terminators
No NAT66 in CPE● IPv6 IPoE has some technical advantages○○○

Faster (1Gbps vs 200Mbps for residential)
No tunneling
No NAT66■■No multiprefix problem
Wide support in common OSes and routers, Japanese and international● In the long term, lower infrastructure cost is good for everyone

Google Confidential and ProprietaryIssues with current 案４
1. Competitive landscape○

Only 3 VNEs can use it■

All others have to outsource operation to VNEs

2. Complicates operational support○Operations outsourced to VNEs■

Increases troubleshooting / support costs

3. Higher cost to ISPs○○

Not part of NGN basic service
ISP must Intra-prefecture traffic can only carried by NGN, not ISP■

Only POIs are in Tokyo (東) and Osaka (西)4. Complex application process○

Currently being addressed

Google Confidential and ProprietaryIncreasing number of VNEs and POIs
● The number of IPoE players is expected to increase:○○○

IPv6によるインターネットの利用高度化に関する研究会第18回:「VNE事業者数拡大の目途は立った」「数十程度になるのではと見込んでいる」● Increasing the number of POIs under discussion:○○

IPv6によるインターネットの利用高度化に関する研究会第21回:「尚、相互接続点（POI) [...] VNE事業者様と協議」● This would address some of the issues:○○○

Addresses #1 (broadens competitive landscape)Addresses #2 (ISPs can use 案４ directly instead of through a VNE)
Partly addresses #3● Some issues would still remain

Google Confidential and Proprietary

Cost issue not completely addressed● 案４ not part of NGN basic service○Substantial increase in per-user cost over IPv4-only or 案２● This could be an issue○ Even though 案４ has lower cost, cost to ISPs could be higher○ This could lead ISPs to prefer 案２■ JAIPA already requested 案２ support in NTT home gateway○ But long term, PPPoE provides slower speeds and could cost more
● How to make native IPoE more attractive to ISPs?

Google Confidential and ProprietaryGoogle Confidential and Proprietary2+4=6● Benefits of Option 2○○○○Many ISPs
Multiple POIs
Part of NGN basic service
Allows bigger than /64 via
DHCPv6 prefix delegation● Benefits of Option 4○○○

Save money, maintenance, andpower by not tunneling
1 Gbps speeds
Compatible with common OSes

● Combined into Option 6○

Multiple native IPv6 ISPs■○○○

Some will resell to smaller, virtual ISPs who want roaming

Multiple POIs
DHCPv6 prefix delegation even if user does not have 光電話
Lower long-term capital and operational costs
Google Confidential and Proprietary

A way forward?
● It may be possible to achieve consensus on 案６○

Requires discussion between NTT東西, ISPs, VNEs, MIC...

● If consensus, 案６could be included in basic NGN service○○○

Would resolve the cost issue
Would ensure low-cost, fast, high-quality, IPv6 access in long term
Would benefit users, ISPs, NTT, and the industry as a whole

Google Confidential and Proprietary

Questions?

Google Confidential and Proprietary