1 / 15

6bone planning issues

6bone planning issues. David Kessens & Bob Fink APNIC – Address Policy SIG Taipei 27 Feb 03. 6bone background. The 6bone was created in March 1996 by the IETF community as a way to test its IPv6 standards and implementations

kert
Download Presentation

6bone planning issues

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. 6bone planning issues David Kessens & Bob Fink APNIC – Address Policy SIG Taipei 27 Feb 03 APNIC 6bone planning issues

  2. 6bone background • The 6bone was created in March 1996 by the IETF community as a way to test its IPv6 standards and implementations • Its current address authority comes from RFC 2471, via the original IANA, Jon Postel • Its focus has moved on to: • a place for early experimentation with routing and operational procedures; • a place to evolve practices useful for production IPv6 prefix allocation; • a place to provide bootstrap qualification for production IPv6 address prefix allocation; • a place to develop IPv6 applications; • a place for early users to try using IPv6 in their hosts and networks. APNIC 6bone planning issues

  3. Primary 6bone issues – 2002/2003 • Making it a robust testbed • Discussions underway, draft in progress • Focuses mostly on keeping the backbone cleaned upand unsnarled from long tunneling transit times • Transitioning the registry under the RIRs • Discussions started last year with RIRs • Currently unclear what is next • Planning for the phaseout of the 6bone • We need to have a solid plan for a phaseout that is openly discussed and decided by the IETF community • This is necessary to avoid confusion over what the future of the 6bone is… APNIC 6bone planning issues

  4. Making a robust testbed • As v6 testbed networks come and go they leave behind unclear situations in the backbone • No longer responsive but they are still in place with previous agreements • Thus we try to identify these situations and take steps to either clean them up or take them out of the loop • They simply don’t exist, and/or have any v6 effort • So we try to reclaim the allocations • Routing policies for backbones often cause bad peerings and overly long tunnel transit times • Thus we need to have good guidelines that make it clear what needs to be done • A draft is underway … (as ever, with the 6bone, the journey itself is the reward!) APNIC 6bone planning issues

  5. Transitioning the registry under the RIRs • In early 2002 discussions were started with the RIRs driven by two issues • Clarifying the role the 6bone address registry has with respect to the RIRs IPv6 address registry • Gaining access to the ip6.arpa reverse registry • Not at issue, contrary to common perception, is that it was being done because Bob Fink was retiring • Bob always intended to stay involved to assist in any appropriate way • …or that the IETF ngtrans wg was closed thus a new home was needed • The IETF still feels responsible for the 6bone APNIC 6bone planning issues

  6. Other issues related to RIR involvement • During the course of early discussions, the RIRs’ management made it clear that they could not speak to the issue of how long the 6bone allocation authority would last • Rather, it was an issue that the IETF and/or the IANA would have to deal with • To this end, a discussion was opened within the IETF on 6bone phaseout planning • Who would oversee operations? • Even though the 6bone came under the IETF ngtrans wg, it really had almost nothing to do with its operational policies • The 6bone community itself controls its policies and everyone expects that it will continue to do so • Is the 6bone separate from the production Internet? • Emphatically no! • However, the choice is for each 6bone network to make, i.e., don’t peer with it if you don’t want to APNIC 6bone planning issues

  7. Comments from the 6bone community • Many comments came from the 6bone community, but most relevant ones focus on: • Having to pay for testbed addressing when they haven’t been in the past • Note that many 6bone participants (at all levels) do so to get experience and in the process convince their organizations that there is something worth paying for, i.e., the price is an issue, no matter how small it is • Having to go through more complexity • It isn’t clear if this is a real issue as we don’t know what a pTLA-level request process might be • Also, this may be a holdover of dislike of necessary procedures for scarce IPv4 address space • What is pay for service when the 6bone is a volunteer effort… RIR services aren’t needed • Unwillingness to pay for service and then be expected to hand our free address services to downstream users APNIC 6bone planning issues

  8. Comments from the RIR community • Many comments have come from the RIR community as well • I would paraphrase the single largest concern as“…why should the 6bone community get cheaper services than the dues paying members…?” • Also, the RIRs are supposed to recover costs for providing their services. Giving away any service would seem to go against this. • And a corollary to the above is, if the RIRs are just covering costs for a special service to the 6bone, what are the RIRs doing to their regular customers • Why should RIR members care about the 6bone? Let 6bone do their thing, and the RIRs theirs • The above are Bob’s readings of the concerns and comments, not any RIR presentation of them APNIC 6bone planning issues

  9. Well then, what’s next? • It isn’t clear if this proposal should proceed • Many of the concerns seem almost cultural and may be too hard to overcome • If the 6bone phaseout planning results in a specific and concrete plan for 6bone shut down, is the primary concern of the 6bone as a competing IPv6 registry still relevant? Is a transfer to the RIRs any longer relevant • What would not continuing with this proposal mean for ip6.arpa registry for the existing 6bone? Does it even matter? APNIC 6bone planning issues

  10. 6bone phaseout planning • As clearly stated in RFC 2471, the addresses for the 6bone are temporary and will be reclaimed in the future. It further states that all users of these addresses (within the 3FFE::/16 prefix) will be required to renumber at some time in the future. • Since 1999 planning for, and allocation of, IPv6 production prefixes by RIR community has been underway. During 2002 more production IPv6 address prefixes had been allocated than are allocated by the 6bone at the top level. It is generally assumed that this is one reasonable indicator that planning for a 6bone phaseout should begin. • It is generally assumed that there is still some remaining need for the 6bone, at least for current usage that will take time to evaluate and possibly move to production IPv6 networks when possible. APNIC 6bone planning issues

  11. How to plan a phaseout • The original IETF home for the 6bone’s oversight, the ngtrans wg, is now closed and replaced by the v6ops wg that did not include the 6bone in its charter • It was thus assumed that it is appropriate to use the IETF Informational RFC process to determine a 6bone phaseout plan, as well as an appropriate way to get community feedback on the specifics of the 6bone phaseout • In January 2003 a 6bone phaseout planning draft was released: draft-fink-6bone-phaseout-00.txt authored by Bob Fink (IETF v6ops wg co-chair) and Bob Hinden (IETF ipv6 wg co-chair) NOTE that Bob & Bob were both co-authors with Jon Postel of RFC 2471 APNIC 6bone planning issues

  12. Proposed phaseout process • 6bone pseudo TLA's (pTLAs) MAY continue to be allocated until July 1, 2004. Thus after the pTLA allocation cutoff date July 1, 2004, it is REQUIRED that no new 6bone 3FFE pTLAs be allocated • To provide for sufficient planning time for 6bone participants to convert to production IPv6 address prefixes, all 6bone prefixes allocated by the cutoff time specified above, except for allocations withdrawn as a matter of 6bone operating procedures, SHALL remain valid until July 1, 2006 • Thus after the 6bone phaseout date July 1, 2006, it is REQUIRED that no 6bone 3FFE prefixes, of any size/length, be used on the Internet in any form APNIC 6bone planning issues

  13. Phaseout implications • It should be noted that this RFC does not intend to imply that a 6bone prefix holder, whether at the pTLA top level or lower, should seek a production IPv6 address prefix at any specific level • It may be entirely reasonable for a 6bone prefix holder to seek a higher level, or a lower level, IPv6 prefix as their specific needs dictate • It is anticipated that under this phaseout plan the 6bone will cease to operate by July 1, 2006, with all 6bone prefixes fully reclaimed by the IANA • This plan is intended to obsolete RFC 2471, "IPv6 Testing Address Allocation", December, 1998. RFC 2471 would become historic. APNIC 6bone planning issues

  14. IANA Considerations • The IANA MUST reclaim the 3FFE::/16 prefix upon the date specified in 2.0, and MUST make provisions to set it aside from any other uses for a period of at least two years after this date to minimize confusion with its current use for the 6bone (e.g., thus allowing production IPv6 networks to filter out the use of the 3FFE::/16 prefix for a reasonable time after the 6bone phaseout). APNIC 6bone planning issues

  15. What’s next • Current comments mostly agree with the phaseout plan, with a slight preference for a shorter timescale before shut down and an allocation cutoff date closer to the shut down(e.g., Jan 1, 2005 cutoff for a July 1 2005 shut down) • Suggested to make IANA 2-year non-reuse a SHOULD not a MUST to allow for possible other uses • Encourage more discussion • Does this impact the planning for an RIR 6bone registry? APNIC 6bone planning issues

More Related