Hierarchical IPv4 Framework
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IRSG <firstname.lastname@example.org> Cc: The IESG <email@example.com>, <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org> Subject: Re: Experimental RFC to be: <draft-frejborg-hipv4-14.txt> The IESG has no problem with the publication of 'Hierarchical IPv4 Framework' <draft-frejborg-hipv4-14.txt> as an Experimental RFC. The IESG would also like the IRSG to review the comments in the datatracker (http://datatracker.ietf.org/doc/draft-frejborg-hipv4/) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-frejborg-hipv4/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary
Technical Summary (From the Abstract) This document describes a framework for how the current IPv4 address space can be divided into two new address categories: a core address space (Area Locators, ALOC) that is globally unique, and an edge address space (Endpoint Locators, ELOC) that is regionally unique. In the future the ELOC space will only be significant in a private network or in a service provider domain. Therefore, a 32x32 bit addressing scheme and a hierarchical routing architecture are achieved. The hierarchical IPv4 framework is backwards compatible with the current IPv4 Internet. This document also discusses a method for decoupling the location and identifier functions - future applications can make use of the separation. The framework requires extensions to the existing Domain Name System, the existing IPv4 stack of the endpoints, middleboxes, and to routers in the Internet. The framework can be implemented incrementally for endpoints, DNS, middleboxes, and routers. Working Group Summary N/A - IRTF submission Document Quality This document is one of the proposals from RRG. The group did not reach consensus on this proposal, but did agree that it should be published. A consensus check showed 4 members in favor of publication, none opposed, and one bad ballot. Personnel Ralph Droms <email@example.com> is managing the IESG review (RFC 5742). IESG Note From RFC 5742: 1. The IESG has concluded that there is no conflict between this document and IETF work.