home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ngtrans / ngtrans-minutes-97aug.txt < prev    next >
Text File  |  1997-10-10  |  14KB  |  370 lines
  1.  
  2.  
  3. Ngtrans-tools WG meeting
  4. August 12, 1997
  5. Munich IETF
  6.  
  7. Tony Hain  Microsoft chair (co-chair of ngtrans)
  8. Reported by ALain Durand and Tony Hain
  9.  
  10. Discussion:    ngtrans@sunroof.eng.sun.com
  11. Subscribe:     majordomo@sunroof.eng.sun.com
  12. Archive:     ftp://playground.sun.com/pub/ngtrans
  13. Chairs:        Bob Fink rlfink@lbl.gov
  14.         Robert Gilligan gilligan@freegate.net
  15.         Tony Hain tonyhain@microsoft.com
  16.  
  17. Notes for the minutes courtesy of Alain Durand  durand@imag.fr
  18.  
  19. Tools session:     Various reports and plans were presented.
  20.  
  21. Brian Carpenter (IBM, UK) reported that the "6 over 4" draft will be
  22. refreshed with no changes.
  23.  
  24. Tony Hain (Microsoft, US) noted that the charter wording would be
  25. cleaned up to address concerns about the appearance we are mandating a
  26. scenario, and sent back to the list.
  27.  
  28. Jim Bound (Digital, US) presented the NNAT concept as a means of
  29. dynamically assigning v4 addresses as needed for primarily v6 nodes.
  30. Goal is to allow primarily v6 work groups to be deployed soon, without
  31. requiring a permanent address in the v4 Internet. Attaining that
  32. requires core applications be available over the v6 stack sooner. Also
  33. requires a tie between the DNS and some form of DHCP service with a pool
  34. of v4 addresses. Some applications may not need or want connections with
  35. the v4 Internet, and should not be required to implement the extra code.
  36.  
  37. Erik Nordmark (Sun, US) noted that the time to start thinking about
  38. translators to allow v4 only to v6 only has arrived. Some systems may
  39. arrive in the market as v6 only. Erik presented an overview of his ID
  40. (draft-ietf-ngtrans-header-trans-00.txt) and the rules for both
  41. directions. Tunneling v4 in v6 may be required for v4 compatible node
  42. within a v6 only routing system. Another option is a set of stateless
  43. translators that would convert the headers on the fly, but would not
  44. attempt v4 options.
  45.  
  46. Pedro Marques (Cisco, US) discussed ideas about transparent translation
  47. where hosts were unaware of the translator. Does not require tie to DNS
  48. & DHCP, and Cisco has a prototype running. He will submit an ID to the
  49. list for comment.
  50.  
  51. Dan Harrington (Lucent, US) reported that the update to the ID
  52. (draft-harrington-ngtrans-dhcp-option-00.txt) would reflect the assigned
  53. number from IANA.
  54.  
  55. _____________cut
  56. here___________________________________________________________
  57.  
  58. ngtrans-6bone WG meeting
  59. August 12, 1997
  60. Munich IETF
  61.  
  62. Bob Fink ESnet/LBNL chair (co-chair of ngtrans)
  63. Reported by ALain Durand and Bob Fink
  64.  
  65. Discussion:    6bone@isi.edu (6BONE Mailer)
  66. Subscribe:     majordomo@isi.edu     "subscribe 6bone"
  67. Archive:     http://www.ipv6.nas.nasa.gov/6bone/
  68. Chairs:        Bob Fink rlfink@lbl.gov
  69.         Robert Gilligan gilligan@freegate.net
  70.         Tony Hain tonyhain@microsoft.com
  71.  
  72. --------------------------------------------------------
  73. Agenda
  74. --------------------------------------------------------
  75.  
  76. 1. Introduction and agenda / Fink
  77. 2. Status of action items from Memphis / Fink
  78. 3. New 6bone registry, oveview and issues / Kessens
  79. 4. Backbone planning / Fink, Durand, Davies
  80. 5. Test plan for aggregation-based addressing / Fink
  81. 6. Operational issues on the 6bone / various
  82. 7. Implementations in use on the 6bone / Fink
  83.  
  84. --------------------------------------------------------
  85. 1. Introduction and agenda / Fink
  86. --------------------------------------------------------
  87.  
  88. Bob Fink convened the meeting, giving a status report on the 6bone.
  89.  
  90. There are now over 150 sites in 28 countries participating in the 6bone.
  91.  
  92. BGP4+ has been successfully deployed in the 6bone backbon, with 3
  93. interoperable implementations (Cisco, Digital and Telebit), and is rapidly
  94. replacing RIPng, IDRPv6 and static routes in the backbone.
  95.  
  96. The 6bone now has its own domain, 6bone.net, through which the 6bone web
  97. pages and registry database is available.
  98.  
  99. The primary DNS for 6bone.net is located at LBNL, and the secondary name
  100. servers are at RIPE an APNIC.
  101.  
  102. The 6bone web pages are now available at:
  103.  
  104.     http://www.6bone.net
  105.  
  106. The mail list is available by sending email to
  107.  
  108.     majordomo@isi.edu
  109.  
  110. with
  111.     subscribe 6bone
  112.  
  113. in the body of the message.
  114.  
  115. The agenda was accepted without comment.
  116.  
  117. --------------------------------------------------------
  118. 2. Status of action items from Memphis / Fink
  119. --------------------------------------------------------
  120.  
  121. Bob Fink reviewed the status of 6bone action items from the Memphis IETF.
  122.  
  123. 2.1 CAIRN Backbone Proposal - Allison Mankin
  124. Allison Mankin will readdress this issue at the December meeting.
  125.  
  126. 2.2 RFC1987 changes to use virtual IPv6 provide ID - Hsin Fang
  127. Hsin Fang removed this item from further consideration as the new Test
  128. Aggregation-based addressing plan supercedes it.
  129.  
  130. 2.3 Aggregation-based Addressing structure for the 6bone - Bob Fink
  131. Bob Fink will present his plan, as issued previously to the 6bone mail
  132. list, under agenda item 5. below.
  133.  
  134. 2.4 I-D "Representing IPv6 Tunnels in RPSL" - David Meyer
  135. This item is now closed as it has been implemented in the new 6bone registry.
  136.  
  137. 2.5 New 6bone Registry - David Kessens
  138. David Kessens will present the status of the registry under agenda item 3.
  139. below.
  140.  
  141. 2.6 DNS for localized 6bone routing registry information - Bill Manning
  142. Bill Manning would like to continue pursuing this idea.  He earlier told
  143. the chair that he would come forward with a plan in the near future as to
  144. how he would like to proceed.  The chair will close this item and await
  145. further submission from Bill before reactivating it.
  146.  
  147. 2.7 Volunteer for I-D on requirements for new 6bone infrastructure - Bob Fink
  148. Bob Fink reported that he has previously had several offers to help on such
  149. a draft.  He noted that when the address conversion and backbone
  150. restructuring of the 6bone is done, he will reopen this action as
  151. appropriate.
  152.  
  153. 2.8 Survey of host and router implementations on the 6bone - Bob FInk
  154. Bob Fink will report on this survey under agenda item 7 below.
  155.  
  156. --------------------------------------------------------
  157. 3. New 6bone registry, oveview and issues / Kessens
  158. --------------------------------------------------------
  159.  
  160. David Kessens reported that the conversion away from the old ftp-style
  161. 6bone registry to the new RIPE-style 6bone registry was completed in early
  162. June.  He autmatically mapped over all entries.  The status of the new
  163. database is that there are 172 site objects and 130 persons registered.
  164. The query level is at ~200 per day.  There are two mirror sites:
  165. whois.nic.fr and whois.ra.net,
  166.  
  167. David noted that his draft on the registry specification,
  168.  
  169.               draft-ietf-ngtrans-6bone-registry-01.txt
  170.  
  171. has been updated and it would be processed as an Informatinal RFC.
  172.  
  173. David also noted that his registry was ready and capable of becoming an
  174. address registry for Aggregation-based Unicast addresses, if it was
  175. desirable.
  176.  
  177. --------------------------------------------------------
  178. 4. Backbone planning / Fink, Durand, Davies
  179. --------------------------------------------------------
  180.  
  181. Bob Fink spoke about the need to restructure the backbone to minimize
  182. peering, as opposed to full mesh peering, and that the renumbering for
  183. aggregation-based addressing might be a good time to accomplish this.  He
  184. also noted the importance of moving to BGP4+ peering.
  185.  
  186. Alain Durand, of the G6 project in France, spoke on plans to restructure
  187. the G6 collaborators for the coming readdressing required for the move to
  188. Aggregation-based addressing.
  189.  
  190. Guy Davies, of UUNET/UK, spoke on plans to restructure the UK academic
  191. 6bone backbone, both to cleanup the topology and ready for the readdressing
  192. required for the move to Aggregation-based addressing.  He also noted the
  193. problems in the current 6bone backbone with sloppy peering arrangements and
  194. poor aggregation.
  195.  
  196. A major problem for the UK academic networks is that the 6bone backbone
  197. topology is too complex, there is not optimal aggregation, and there are
  198. bad RIPng problems. proposal: get accademic sites to single homed OR use
  199. BGP4+ map of Uk sites:
  200.  
  201. The graphs from Guy's presentation are available at:
  202.  
  203.     http://www.pipex.net/~guyd/6bone/IETF-presentation/
  204.  
  205.  
  206. --------------------------------------------------------
  207. 5. Test plan for aggregation-based addressing / Fink
  208. --------------------------------------------------------
  209.  
  210. Bob Fink noted that the most important work ahead of the 6bone is
  211. conversion to the new Test address format for Aggregation-based Global
  212. Unicast addressing that is about to move to experimental RFC status.
  213.  
  214. At a meeting later in the IETF week (Thursday at 11:30), those interested
  215. in the 6bone backbone planning met to discuss issues for the
  216. restructuring/cleanup of the backbone, as well as the address conversion.
  217. This meeting was reported in an email to the 6bone mail list that evening,
  218. and is reproduced as an addendum to these minutes.
  219.  
  220. Then Bob presented the plan for 6bone use of the Test address format, which
  221. is the material presented on the 6bone mail list in late May.  This
  222. material is reproduced as an addendum to these minutes.
  223.  
  224.  
  225. --------------------------------------------------------
  226. 6. Operational issues on the 6bone / various
  227. --------------------------------------------------------
  228.  
  229. Matt Crawford spoke on multihoming on the 6bone.  He noted that a site
  230. multihome to the same provider needs only one prefix if that provider knows
  231. how to handle the extra route.
  232.  
  233. When connected to two or more providers it will (most likely) be necessary
  234. to have multiple prefixes.
  235.  
  236.  
  237. How much interconnection for backbone sites?  There is too much as of
  238. today. This is recognized as one topic for discussion as the backbone is
  239. restructured for the new addressing format.
  240.  
  241.  
  242. --------------------------------------------------------
  243. 7. Implementations in use on the 6bone / Fink
  244. --------------------------------------------------------
  245.  
  246. Bob Fink reported ion his survey of IPv6 implemenations.
  247.  
  248. This survey may not be completely accurate, however, it is fairly close
  249. having been circulated for comment on the 6bone mail list.
  250.  
  251. Host implementations in use on the 6bone are:
  252.  
  253. Digital OpenVMS             Digital Unix
  254. FTP Software Win95          Hitachi NR60
  255. IBM AIX                     Inria BSD
  256. Linux                       SICS HP-UX
  257. Sun Solaris                 UNH for BSD
  258. NRL for BSD                 WIDE Hydrangea for BSD
  259. WIDE ZETA for BSD           WIDE v6d
  260.  
  261. Host implementations in use on the 6bone are:
  262.  
  263. Bay                         Cisco
  264. Digital                     Fujitsu LR550
  265. Hitachi NR60                Inria BSD
  266. Linux                       Merit MRT
  267. NRL for BSD                 Telebit
  268. WIDE Hydrangea for BSD      WIDE ZETA for BSD
  269. WIDE v6d
  270.  
  271. --------------------------------------------------------
  272. Addendum - Report of ad hoc 6bne Backbone planning meeting
  273. --------------------------------------------------------
  274. 6bone backbone planning meeting - 14 August 1997, Munich, DE.
  275.  
  276. Alain Durand held a BOF for those interested in 6bone backbone planning
  277. under the new test aggregation address format.  There were 27 people in
  278. attendance.
  279.  
  280. Alain Durand (G6, FR) spoke on the need to minimize backone tunnels to
  281. clean up routing.  There were comments for this, explaing the reasons why
  282. it is needed at this time, and comments as to why we shouldn't worry about
  283. this.
  284.  
  285. Stephen Stuart (Digital-ca, US) spoke on reasons to cleanup peering, and to
  286. have multiple interconnect points for ISP TLA's.
  287.  
  288. Matt Crawford showed various multi-prefix scenarios.
  289.  
  290. There was a general consensus that there was a need to simplify the 6bone
  291. bacbone topology.
  292.  
  293. Bob Fink (ESnet/LBNL, US) then led a discussion to generate a plan for
  294. readdressing and backbone restructuring. This discussion led to the
  295. following general agreements:
  296.  
  297. 1. that we assign Testing pTLAs (i.e., pseudo TLAs assigned from the NLA1
  298. field of the 6bone Test address allocation) from the Test Aggregation
  299. addressing I-D as follows:
  300.  
  301. TELEBIT/DK    3FFE:0100::/24
  302. SICS/SE        3FFE:0200::/24
  303. G6/FR        3FFE:0300::/24
  304. JOIN/DE        3FFE:0400::/24
  305. WIDE/JP        3FFE:0500::/24
  306. SURFNET/NL    3FFE:0600::/24
  307. ESNET/US    3FFE:0700::/24
  308. CICNET/US    3FFE:0800::/24
  309. ISI-LAP/US    3FFE:0800::/24
  310. NWNET/US    3FFE:0A00::/24
  311. VIAGENIE/CA    3FFE:0B00::/24
  312. CISCO/US    3FFE:0C00::/24
  313. ANS/US        3FFE:0D00::/24
  314. IFB/UK        3FFE:0E00::/24
  315. NRL/US        3FFE:0F00::/24
  316. CSELT/IT    3FFE:1000::/24
  317. UUNET/UK    3FFE:1100::/24
  318. DIGITAL-CA/US    3FFE:1200::/24
  319. BAY/US        3FFE:1300::/24
  320. UNI-C/DK    3FFE:1400::/24
  321.  
  322. Note: we started at 1 because Bob is nervous about using 0 :-)
  323.  
  324. 2. that we establish October 1 as the start date for renumbering the
  325. backbone to testing aggregation addresses, with the goal of November 1 for
  326. coming online.
  327.  
  328. 3. that all backbone sites will peer with BGP4+, and only BGP4+.
  329.  
  330. 4. that the old testing addresses (RFC 1897) be discontinued on the
  331. backbone as early as October 1 (by sites already renumbered) and not later
  332. than November 1 when the newly addressed backbone is scheduled to be fully
  333. online.
  334.  
  335. 5. that a call for new pTLA candidates be issued immediately, for inclusion
  336. in the October 1 renumbering/restructuring, where the criteria to be
  337. applied for inclusion is willingness and ability to actively participate in
  338. this timeframe, and demonstrated experience with IPv6 and the 6bone.
  339.  
  340. 6. that a call for existing backbone sites (given a pTLA above) be made to
  341. decide themselves if they are able to participate in this renumbering/
  342. resructuring effort, and be encouraged to give back their pTLA assignment
  343. for now if they aren't able to participate.  (Note:  any site doing this
  344. can easily reapply at a later time.)
  345.  
  346. --------------------------------------------------------
  347. Addendum - Call for 6bone Backbone participants email to 6bone list
  348. --------------------------------------------------------
  349. Per the 6bone backbone ad hoc meeting in Munich, I am calling for those
  350. interested in being an early 6bone test pTLA (i.e., pseudo TLAs assigned
  351. from the NLA1 field of the 6bone Test address allocation) when the
  352. renumbering to the new Aggregation-based unicast address format is started
  353. on 1 October.
  354.  
  355. Requirements are willingness and ability to actively participate in this
  356. timeframe, and demonstrated experience with IPv6 and the 6bone.
  357.  
  358. Please send your requests to become a 6bone pTLA to the 6bone mail list
  359. with text sufficient to describe your interest and qualifications.
  360.  
  361. I will assign test pTLAs to all reasonable request at this time.
  362.  
  363. Thanks,
  364.  
  365. Bob
  366.  
  367. -end
  368.  
  369.  
  370.