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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf