1 / 5

IPng Addressing Document Status

IPng Addressing Document Status. Thomas Narten narten@raleigh.ibm.com March, 2001. Addressing Architecture. Currently under IESG discussion Make clear that implementations must treat all "non-special" addresses as global unicast Downplay reference to RFC2374 (Unicast Aggregatable)

meda
Download Presentation

IPng Addressing Document Status

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. IPng Addressing Document Status Thomas Narten narten@raleigh.ibm.com March, 2001

  2. Addressing Architecture • Currently under IESG discussion • Make clear that implementations must treat all "non-special" addresses as global unicast • Downplay reference to RFC2374 (Unicast Aggregatable) • Other editorial edits (no impact on implementations) • -04 ID addresses some issues, another rev needed • Approval as Draft Expected

  3. RFC2374: "Global Unicast Aggregatable Addresses" • IESG unwilling to advance in current from • Not really appropriate for Standards Track • Topic of document has few implications for implementations • Size of TLAs, NLAs, etc. may change in future • Address assignment policy is the domain of RIRs • IPv6 architecture defines /64 boundary • /48 boundary not required by architecture, though good technical arguments for having it • Other boundaries in routing part managed by RIRs

  4. RFC 2374 (cont.) • Recommendation: • Engage the RIRs on topics covered in 2374 • Cooperative effort: • IETF provides input on technical issues • RIRs develop and adopt allocation policies • Separate documents (with different focus) may result • No change to existing allocations expected • No change in policy without extensive public review (both in IETF & RIRs) • May result in evolution of future policy

  5. Met With RIRs • IPng Chairs and ADs met with RIRs this week • Initial discussion positive

More Related