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

From: Scott Brim <[email-masked]>
Date: Fri, 16 Apr 2010 21:57:08 -0400

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:
> 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: Fri, 16 Apr 2010 21:06:31 -0500

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:
>> sending to<ASN>  +<IPv4 style address>  since the ASN to 96-bit ID

---

From: William Herrin <[email-masked]>
Date: Sat, 17 Apr 2010 19:33:41 -0400

On Fri, Apr 16, 2010 at 9:57 PM, Scott Brim <[email-masked]> wrote:
> Unfortunately there isn't much new under the sun.
>
>> addressing model.

Hi Matthew,

Welcome!

Though intended as a half-joking "so-there" when someone years ago
claimed there was no conceivable way we could have extended IPv4, I'd
welcome your thoughts on: http://bill.herrin.us/network/ipxl.html

> <16 or 32-bit ASN> <96-bit ID> <32-bit IPv4 style address>

One of the things we've discovered over the course of our
investigations here is that overloading multiple functions on a single
number is an often regretted decision. How much less trouble would we
be in today if the protocol stack didn't use the source and
destination IP addresses in the process of associating a TCP packet
with its connection?

The AS number already has a purpose. It isn't forwarding packets.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Matthew <[email-masked]>
Date: Sat, 17 Apr 2010 19:04:13 -0500

On 4/17/2010 6:33 PM, William Herrin wrote:
> On Fri, Apr 16, 2010 at 9:57 PM, Scott Brim<[email-masked]>  wrote:
>    

I thought about extended IPv4 and had heard that it was proposed. It 
would be a good idea but when I started thinking about my proposal I 
realized that a larger address space that leaves IPv4 space intact and 
gives a hierarchy would be more ideal. A true hierarchical address 
structure would be much more efficient.

>> 96-bit identifier based on region, service provider, etc>  <32-bit
>> IPv4 style address>
>>

Even if the ASN portion of this concept was left out we would gain the 
benefit of backwards compatibility + hierarchy in the address. 
Multi-homing would still lead to increased routing tables but IPv6 has 
this problem too, as does IPv4. Although it is conceivable that we could 
mitigate some of the table size by allowing multi-homing AS's to use a 
portion of the 96-bit ID where most of the duplicate address could be 
hidden lower in the hierarchy.

Although we don't have to base this structure on geographic location I 
still believe having a system more like house addressing is better in 
the long run. However, instead of geographic cities, etc. there are 
Service Providers, and possibly large companies which would make up the 
96-bit ID. It works on a massive scale on Earth and I think it could be 
adapted for IP Addressing. It turns routing into a distributive function 
where not every route needs to be on backbone routers. Just the major 
Provider's.

I know this is also how we want IPv6 to go but in the end IPv6 is a flat 
128-bit space which is then being logically folded into a hierarchy. 
This can (and probably will) lead to the messed up tables we see today.

---

From: Paul Jakma <[email-masked]>
Date: Sun, 18 Apr 2010 09:21:25 +0200 (CEST)

On Sat, 17 Apr 2010, William Herrin wrote:

> investigations here is that overloading multiple functions on a 
> single number is an often regretted decision.

On the other hand, in order to get good performance one sometimes 
/must/ fold together things.

That is to say, a highly multi-"dimensional" architecture - where 
every little concept is called out separately - may be as "bad" as 
one with too few "dimensions". The trick of course is to find /just/ 
the right balance.

E.g. if you separate out locators from end-host IDs you may solve 
problems with the scalability of communicating the state of locators, 
but you substitute for it the problem of communicating the state of 
end-host IDs. Etc..

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
"Earth is a great, big funhouse without the fun."
 		-- Jeff Berner