1. IPv6 Routing Considerations Masaru Mukai / POWERDCOM Kuniaki Kondo / IIJ

2. APNIC SIG-IPv62 2002/03/05 Background This talk shows the result of “IPv6 Operation Study Group(IPv6-OPS)” discussion in Japan IPv6-OPS was held twice over night meeting and BoF in JANOG8 Meeting last year.  JANOG = Japan Network Operators’ Group http://www.janog.gr.jp/ IPv6-OPS has “Routing Sub-Group”.  This group focuses “ISP Backbone Routing Issues”.

3. APNIC SIG-IPv63 2002/03/05 IPv6-OPS Routing Sub-Group Motivation  Address architecture will change in IPv6. Address Length is 128 bit Address allocation scheme will change  We would like to know what is difference between IPv6 and IPv4. Goal  This group survey how IPv6 address architecture influences IPv6 routing?  If possible, this group hopes to make typical IPv6 network models.

4. APNIC SIG-IPv64 2002/03/05 Agenda Multi-homing EGP IGP

5. APNIC SIG-IPv65 2002/03/05 Multi-Homing Overview  There are some techniques to do multi- homing such as using BGP, using NAT, etc..  In IPv4, some ISPs use to connect inter-ISP or between ISP and customer for redundant.  Customer want to have redundant line and to do load-balancing same as IPv4 network, when IPv6 come.

6. APNIC SIG-IPv66 2002/03/05 IPv4 Multi-Homing One AS announces a part of address block which was allocated for other AS by registry. It makes to increase number of full routes.  One AS customer want to do multi-homing, but their network scale does not so large as getting AS number.  ISPs probably allow this configuration based on customer requires. To increase number of full routes makes some problems.  For example, if number of full routes increase continuously, then BGP convergence time also increase.

7. APNIC SIG-IPv67 2002/03/05 Category of Multi-Homing BGP based (A organization has AS number and PA address)  Anything will not change. Announcing PI address  Currently, Registries do not allocate IPv6 PI address. punching hole  The number of IPv6 punching holed routes are unknown. Multi prefix  Some prefixes are assigned by each upstreams.  Source address selection can be used This behavior is different each implementation. RFC3178 model  This is possible solution, but it needs more costs such as operation cost, line cost, etc.

8. APNIC SIG-IPv68 2002/03/05 RFC3178 Model ISP AISP B PA(A) + PA(B) RouterBRouterA PA(A) PA(B) PA(A)

9. APNIC SIG-IPv69 2002/03/05 Problems of RFC3178 Model Problems of using tunnel  To separate responsible area is difficult.  Responsible area can not separate clearly.  There is security problem why traffic might through unwilled ISPs.  There are no-method to limit bandwidth of tunnel lines. If this model does not use tunnel, then it needs more leased lines. It means that it needs more line costs.

10. APNIC SIG-IPv610 2002/03/05 punching hole ISP AISP B User X A The Internet P(A) B A B

11. APNIC SIG-IPv611 2002/03/05 Problems of punching hole Increasing number of routes  Increasing route convergence time  Needs more powerful routers  It makes more cost to provide ISP services

12. APNIC SIG-IPv612 2002/03/05 Multi prefix P(A) P(B) ISP AISP B P(A) P(B) AB host

13. APNIC SIG-IPv613 2002/03/05 Problems of Multi Prefix There are some implementations, but behavior is different each implementations.  Every host must be cared which prefix is better for sending packets. Every host must select source address. Both of backup and load-balance are defective in multi-prefix situation. A router which can do policy routing must be more generic.

14. APNIC SIG-IPv614 2002/03/05 Agenda Multihoming EGP IGP

15. APNIC SIG-IPv615 2002/03/05 EGP Overview  People needs a solution for IPv6 traffic control  Announced prefix will decrease. It makes that traffic will be concentrated to some of routers in ISP.

16. APNIC SIG-IPv616 2002/03/05 Problems of Traffic Control In IPv6 network, ISPs can not control traffic using separated prefixes.  If ISPs announce more specific routes, then number of full routes increase tremendously. In some cases, inter-AS traffic might concentrate specific border routers.

17. APNIC SIG-IPv617 2002/03/05 Traffic Control Solutions for IPv6 Upstream ISPs control traffic  prepend, community New Method  To use MPLS  To propose BGP-5 ISPs announce more specific routes.  Number of full routes increase tremendously.

18. APNIC SIG-IPv618 2002/03/05 Agenda Multi-Homing EGP IGP

19. APNIC SIG-IPv619 2002/03/05 IGP Our discussion summary  Networks might have more number of internal routes than number of external routes.  We would like to consider new network design for IPv6 which is considered aggregation of IP blocks.  If we design network same as IPv4, then IPv6 networks probably have more number of internal routes than IPv4 network. It depends on network design

20. APNIC SIG-IPv620 2002/03/05 Problems of IGP Aggregating prefixes is necessary for decreasing number of internal routes. One of possible way is that prefixes aggregate for each POPs.  Address blocks are assigned to POPs according to number of lines or forecast of number of customers.

21. APNIC SIG-IPv621 2002/03/05 Conclusion Much Much bigger address spaces  Potential number of external routes in future Multi-homing  No PI(Provider Independent) address for enterprises  Punching hole allowed? Any criteria? Aggregation  /48 static assignment per a customer needs special design consideration about aggregation in ISP internal networks.  How can address policy supports this? Traffic engineering  Less external routes to be announced make TE harder.

22. Acknowledgements

23. APNIC SIG-IPv623 2002/03/05 discussion member(1/2) Akihiro InomataFujitsuChair Masaru MukaiPowerdComCo-Chair Kuniaki KondoIIJ Tomohiko KurahashiIIJ Rie ShimadaPanasonic Toshihiro ArakiJapan Telecom Yasushi EndoJapan Telecom Tomohide NagashimaJapan Telecom Tsuyoshi TomochikaNTT Communications Hiroyuki TanahashiNTT Communications Yasuhiro ShirasakiNTT Communications Akira NagakawaPowerdCom Ryuuichi TakashimaPowerdCom Teruo WatanabePowerdCom Toshio TachibanaAni&Company

24. APNIC SIG-IPv624 2002/03/05 discussion member(2/2) Tomohiro FujisakiNTT Communications Takashi AranoAsia Global Crossing Kazuhiko NakaharaNEC/BIGLOBE Koichiro FujimotoNEC Corporation Hiroki IshiharaNEC Corporation Ikuo NakagawaIntec Web & Genome Informatics Tomohiko KusudaIntec Web & Genome Informatics Kenichi NagamiToshiba Masahito OmoteSapporo Medical University Masamichi Miyaji Sapporo Medical University Satoshi KobayasiNextec Shiro NiinobeNTT West Hirotaka AsaiNTT West Yoshiyuki EzuraIRI Akinori MaemuraEquant

25. Questions?