Subject: Re: [iucg] Idea for IPv4 addition or extension

From: JFC Morfin <[email-masked]>
Date: Sun, 18 Apr 2010 18:52:34 +0200

Dear Matthew,
the main user expectation is permanent IP address and global scope 
IDv6 (IPv6 interface ID).
I am not sure how your idea support this need.
jfc

At 21:07 16/04/2010, Matthew wrote:
>I would like to propose the following concept for discussion. The idea
>is to either extend IPv4 or create a new protocol that would work with
>IPv4 in order to allow a backwards compatible, yet hierarchical
>addressing model. The format is ruff and I wish others to evaluate its
>feasibility.
>
>The general layout of a fully-unique address follows:
>
><96-bit identifier based on region, service provider, etc> <32-bit
>IPv4 style address>
>
>In addition, organizations with an ASN would have the following
>fully-unique address:
>
><16 or 32-bit ASN> <96-bit ID> <32-bit IPv4 style address>
>
>ASN's could be registered to multiple Service Providers without making
>a large mess to the tables.
>
>Individual hosts would only use their IPv4 style address for local
>access and wouldn't need the full address unless talking outside their
>organization and/or ISP.
>
>Internet routing tables would only need 96-bit IDs and BGP tables
>would only need ASN to 96-bit ID mappings.
>
>When talking to a host that has an ASN you could get away with only
>sending to <ASN> + <IPv4 style address> since the ASN to 96-bit ID
>would be mapped on the Internet and the local ISP would then know
>where to route the IPv4 style address once it was within their area.
>
>This could be done by extending IPv4 or by creating a new protocol,
>i.e. Area Routing Protocol (AP for short).
>
>During transition, legacy IPv4 hosts would talk to a gateway device
>which would know its 96-bit ID and allow communication with the new
>protocol.
>_______________________________________________
>Ietf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf

---

From: Matthew <[email-masked]>
Date: Sun, 18 Apr 2010 19:06:09 -0500

> I am not sure how your idea support this need.

My main reason for this was to allow IPv4 backwards compatibility and to 
force summarization of sorts.

IDv6 could be accomplished by using 32-bits of the 96-bit ID to combine 
with the lower 32-bit IPv4 address.

I can think of too many examples throughout history when the expected 
outcome never happens and things end up right back where they were.

IPv6 will start out clean, then exception after exception will occur in 
order to allow organizations to do all sorts of crazy things. In 
addition, 100% IPv4 compatibility would be a great benefit.

---

From: jefsey <[email-masked]>
Date: Mon, 19 Apr 2010 09:57:37 +0200

Here is the mail background of the answer received from Matthew.
I will have some questions I will raise in another mail.

At 03:57 17/04/2010, Scott Brim wrote:
>Unfortunately there isn't much new under the sun.  This appears to be a
>combination of geographic addressing (various sources, e.g. Steve
>Deering and Tony Hain) and RFC1955.  Geographic addressing has
>deployability issues -- search for archives of those arguments.  The
>problem with mapping based on ASs is that they are the wrong granularity
>for external routing.  They are either too coarse (different prefixes
>within an AS need different treatment) or too fine.
>
>I've CCed the Routing Research Group.  I suggest you take further
>discussion there, but remember what's said about mud-wrestling with a pig.
>
>Scott
>
>Matthew allegedly wrote on 04/16/2010 15:07 EDT:

At 04:06 17/04/2010, Matthew wrote:
>Thanks for the comments and the forward to [email-masked].
>
>Geographic was just an example; I left it intentionally vague for 
>discussion purposes.
>
>It partially borrows from OSI's addressing but with the twist of 
>full IPv4 address support and the fact that there are at least 3 
>distinct parts to the full address which can be used independently. 
>If you look closely it also has some DNS type qualities as well, but 
>my main vision is to have an address structure that more mimics 
>other forms of addressing while making ISPs the network entities 
>that each supply their full set(s) of IPv4 address space; while 
>maintaining complete backward compatibility with IPv4 during migrations.
>
>Thanks again, and I'll direct future discussions to the referenced list.
>
>
>-- Matt
>
>
>
>On 4/16/2010 8:57 PM, Scott Brim wrote:
>>Unfortunately there isn't much new under the sun.  This appears to be a
>>combination of geographic addressing (various sources, e.g. Steve
>>Deering and Tony Hain) and RFC1955.  Geographic addressing has
>>deployability issues -- search for archives of those arguments.  The
>>problem with mapping based on ASs is that they are the wrong granularity
>>for external routing.  They are either too coarse (different prefixes
>>within an AS need different treatment) or too fine.
>>
>>I've CCed the Routing Research Group.  I suggest you take further
>>discussion there, but remember what's said about mud-wrestling with a pig.
>>
>>Scott
>>
>>Matthew allegedly wrote on 04/16/2010 15:07 EDT:
>>
>>>sending to<ASN>  +<IPv4 style address>  since the ASN to 96-bit ID

---

From: JFC Morfin <[email-masked]>
Date: Tue, 20 Apr 2010 02:25:06 +0200

>I will have some questions I will raise in another mail.

 From what I gather, Matthew, your idea is to split what could also 
be an IPv6 address into a header and an IPv4 address. This is a 
numbering plan organization? Initially there were five of them left 
free (IPv4, IPv6 IETF and multicast being documented - using the 
first 3 bits), ITU as a candidate for managing one. I am not sure if 
these are still the case with the IETF's lack of "state of current 
dreams" report.

Your idea is not far from (could be included in) the one I proposed 
some years ago - which is briefly documented (in French) at 
<http://afrac.org/uninum.pdf>http://afrac.org/uninum.pdf - I could 
not comment on it today :-) as I do not recall everything, and it has 
an <http://uninum.org/>http://uninum.org IUCG preparatory page.

There are, as usual, three approaches from:

(1) incremental, from RFCs:  IETF/IRTF concerning the entire Internet
(2) disruptive, from the state of the art: engineers being upset 
about the lack of an IETF accepted solution and proposing one
(3) architectural, from reality: the users' expectations and 
propositions based upon their needed practical open generalized 
simplifications (what IUCG is meant to discuss and propose).

Basically, "the UNINUM proposition is a universal open root for all 
the digital namespaces and the smart automated uses of their 
numbering plans. That universal open root is just an open format that 
permits one to unlimitedly number unique numbering plans. To that, 
the UNINUM numbering plan number (NPN, numéro de plan de numération) 
can then be associated with specialized functions and "paradata" 
(i.e. parallel information, [as thoseMatthew proposes] - such as 
location, confidence, credibility levels, dates of validation, 
certification by registry authorities, crossverification schemes, 
memory translation data; etc.). It can also be proposed resolution 
services, such as resolving the IPv6 address for an IPv4 address or 
vice versa for cross addressing or LISP approaches".

I did not push into that because the priority was to have the 
Internet multiplication architectural solution defined and confirmed. 
Now that it is exemplified by IDNA2008, we need to get it 
acknowledged by the IETF. The IESG response to my appeal is halfway 
through this process. Before proceeding further in the Interplus 
architecture, where UNINUM and its resolution process have their 
part, I would prefer the IAB position on all of this to be clarified 
(or officially delayed). The IESG response is already doing part of 
that, but IAB is the real authority.

The reason for that is the Internet is not in a position to deliver 
most of what we expected from it. However, we clearly know today just 
how it will do it: in using peripheral metaprocesses that are 
organized in an Internet Use Interface (IUI). Our, partly worked out, 
IUI Interplus architecture addresses that need. However, it has to 
use some universal resources that could interfere with IANA's 
resources (presentations, classes, etc.), and that need to be 
administered by someone. This someone has not yet been identified. 
This is why (however it does not change a single bit in any existing 
protocols) it is not entirely neutral to the IETF Internet 
standardization process, which is guided by the IAB.

jfc

>>If you look closely it also has some DNS type qualities as well, 
>>but my main vision is to have an address structure that more mimics 
>iucg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/iucg