1 / 10

IPv6 Address Assignment to End Sites

Thomas Narten narten@us.ibm.com IETF 72 Dublin, Ireland July 31, 2008. IPv6 Address Assignment to End Sites. Goals of 3177bis. Update 3177 based on where we are today Some of the arguments no longer hold Clarify what is architectural vs. operational

diep
Download Presentation

IPv6 Address Assignment to End Sites

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. Thomas Narten narten@us.ibm.com IETF 72 Dublin, Ireland July 31, 2008 IPv6 Address Assignment to End Sites

  2. Goals of 3177bis • Update 3177 based on where we are today • Some of the arguments no longer hold • Clarify what is architectural vs. operational • /48 does NOT appear to be architectural • Clarify the key motivations and principles behind original recommendation • Reaffirm to RIRs key concerns: • End sites should get subnets, not just a /64 • Anticipate growth over multi-year time period • Renumbering into fewer subnet bits is painful

  3. Issues Summary

  4. But 3177 was an IAB Document • Issue: RFC 3177 was an IESG/IAB document, therefore only IAB should update • Response: Perfectly OK for IETF WG to update • There is no “process issue;” IESG/IAB will of course review via normal process

  5. Technical Justification Needed • Issue: Need justification to move away from /48 • RIRs changed HD threshold, recovering one order of magnitude off projected consumption • Changing /48 to /56 saves approximately two more orders of magnitude • While some say “no danger of running out”, others say “it is foolish to be profligately wasteful” • Not an IETF decision, this is RIR policy • RIRs have already moved away from /48 for everyone • This document is not the place for technical analysis

  6. RIR policy “problems” • Some have cited problematical RIR policies as reason to support this document • E.g., /48 requires public whois entry, compromising privacy, whereas no required with a /56 • The way to fix RIR policy problems is via the RIR policy development problem • I agree that 3177bis should not be used to fix problems better fixed elsewhere

  7. Next Steps • Would like to see ID adopted as work item of v6ops‏ • Publish as RFC to update RFC 3177

  8. Backup

  9. RFC 3177: IAB/IESG Recommendations on IPv6 Address Allocations to Sites • Issued September, 2001 • /48 recommendation adopted by RIRs in 2002 • Subsequently, some very large allocations made • RIRs began reviewing policy in 2005 • Continued unhappiness with “one size fits all” boundary • SOHO and business sites get same amount of space • Viewed especially wasteful for home users • Revised both HD ratio and end site assignment size • Now measure end site utilization in terms of /56s

  10. 3177bis History • -00 issued July, 2005 • Fair amount of pushback on some particulars • Significantly revised Nov. 2007 (-03)‏ • Highlight concern of home sites getting /48 • Goals of 3177 can be met with /56 • But, document does not make a formal recommendation • Actual selection of boundary is RIR policy • Update 3177, but don't reclassify it as historic • List the architectural issues with changing boundary • Discussion on list generally supportive

More Related