Subject: Re: [rrg] New draft, the hierachial IPv4 framework

From: Patrick Frejborg <[email-masked]>
Date: Sun, 1 Mar 2009 11:35:10 +0200

Hi Robin,

thanks for taking the time to have a look on the draft!
Comments inline

On Sun, Mar 1, 2009 at 6:47 AM, Robin Whittle <[email-masked]> wrote:
> Hi Patrick,
>
> While I haven't been able to understand exactly how your proposal
>
>   http://tools.ietf.org/html/draft-frejborg-hipv4-00
>
> would work, I think it could not be considered as the best approach
> to the scalable routing problem for the following reasons:
>
> 1 - It involves extensive changes to host stacks, APIs and
>    applications.
>
>    In order to be effective, such as enabling a billion or
>    whatever large number of multihomable end-user networks,
>    without causing scaling problems, the solution needs to be
>    very broadly accepted by most end-user networks of all types and
>    sizes.  They will only do this if there is immediate benefit to
>    them (in months) and very little in the way of risks and costs.
>
>    A primary functional benefit of the Internet is 100% reachability
>    of all hosts.  Any proposal such as yours which involves a new
>    addressing system relying on host changes, means that all hosts
>    adopting the new addressing system will be unreachable by those
>    which have not upgraded their stack, API and applications.

That is the characteristics of the IPv6 solution

>
>    Therefore, your new addressing scheme would only be useful to
>    most users once everyone has adopted it.  In the meantime, there
>    are only costs (actually, impossibility of having all
>    applications rewritten, even if you got the stacks rewritten)
>    and few benefits for anyone who adopts it - so it would never in
>    fact be adopted widely.

This proposal is compatible with the current IPv4 stack, the normal
applications will never be aware of the new extended IPv4 stack - it
is only the raw socket applications that will need to be modified. And
the new and old addressing scheme is compatible as long as the current
distribution of IP prefixes are in place - once the routing
information is started to get suppressed the old IPv4 stack can no
longer communicate outside their AS. Within the AS we will use the
legacy IPv4 stack, now and forever.
The stack will be modified but the API is still the same with some
extensions needed for the raw socket applications.

Also if you add new features (such as mobility) to the stack you can
create a demand to have it upgraded, also the OS vendors needs
something to create a need for upgrades...
I don't see this as a showstopper, it is all about communication.
>
> 2 - Likewise, for routers and ISPs.
>
Nope, no changes to the forwarding plane. Only adding a new element
per AS. Control plane issue is not that hard to improve, similar has
been done for MPLS

> 3 - Your proposal doesn't help with IPv6.  This would be widely
>    regarded as a show-stopper, on the assumption that IPv6 is
>    going to be the future Internet, replacing the IPv4 Internet.
>
>    I am not convinced this is going to happen at all, or any time
>    soon, but for most people in this field, any scalable routing and
>    addressing solution must also have a solution for IPv6.  I am
>    working on solutions for both IPv4 and IPv6.  I think IPv6
>    is likely to achieve significant adoption, at least for cellphone
>    systems, in the next decade.
>
> The architectures used by the core-edge separation schemes LISP, APT,
> Ivip and TRRP could all work for both IPv4 and IPv6, without
> requiring host changes, while supporting packets from non-upgraded
> networks, without creating any new address spaces.  They convert
> parts of the existing IP address space into a special kind, which I
> call "Scalable PI" space, which is highly suitable for end-user
> networks needing multihoming, inbound TE and portability between ISPs.
>
True, but it makes it difficult to implement and harder to maintain

If we look around a little bit on other systems they have more than
one dimension to find a destination. PSTN, they have a hierarchical
numbering structure in place - country code and subscriber number. But
also the mail system, if I need to send you a packet I have to put
street address, city and country on the label. If the mail system
would use a flat addressing scheme we should change all street
addresses to be globally unique - it is doable since we could mix the
letters and numbers so that every street has its own name. Good for
computers but human mind just flip with such approach.
This core-edge separation is like having the post office to fill in
the final addresses for you, why can't I do it myself since I can
lookup the final address if the addressing structure supports that???

And if you don't know the address you probably can get the longitude
and latitude values so you can put that in your GPS in order to get to
the final destination.

In today's Internet we have only longitude available, thus we have
these problems - we are living in flat world and the only thing we
think is behind the horizon is the edge and once we are close enough
we will fall of that cliff.

Adding latitude and we get the following. When I need to contact a
server in Sydney the DNS tells me that the server is located in an AS
with certain RLOC identifier. Here in Finland I don't need to know
anything about the Australian prefixes, I just need to know the
Australian RLOC identifier (and the Finnish prefixes). I put the AU
RLOC as the destination IP address, send the packet towards Sydney and
once the packet is arriving at Sydney the packet just need to get
swapped with a new destination IP address (that has been carried with
the LISP header) so that the packet gets routed upon the prefixes in
Sydney's local RIB/FIB.

There is nothing wrong with the routing architecture, it is the
addressing scheme that is broken.

>
> I have had some thoughts about creating a new (third . . . ) Internet
> using a 64 bit address space built by extending IPv4 IP addresses
> into a gateway for another 2^32 addresses in the new system.
> However, I think there are probably as many problems changing the
> world over to such a new network as there are changing the world over
> to IPv6.
>
> You wrote:
>
>> I do have a presentation available, but lacking a FTP server resource
>
> I can provide a stable home for it and any other material you have
> under some directory such as http://www.firstpr.com.au/ip/xxx/ .

I'll send you the presentation, it is easier to follow how the packet
is routed between AS and also the issues that arises. Thanks!

And we can get rid of the LSR in very long term, once the forwarding
plane is upgraded. The new forwarding plane needs to do the following:
if the destination IP address matches the local RLOC the forwarder
must move the pointer to the EID field of the LISP header and forward
instead on that IP address. But it requires that the following routers
supports this functionality and also that the stack is aware of this
kind of possibility. This is very very very long term...Not sure if I
add this to the draft, have to think about it for a while...

-- patte

>  - Robin

---

From: Robin Whittle <[email-masked]>
Date: Mon, 02 Mar 2009 17:57:39 +1100

Hi Patrick,

> That is the characteristics of the IPv6 solution

I agree.

> is only the raw socket applications that will need to be modified. 

I am not sure of what the difference is between "normal" and "raw
socket" applications.  Can you explain this and provide some examples
of each?

However, my point is that hosts using the new address space your
system provides will be unable to communicate with any application
which does not meet all these requirements:

  1 - The application has been upgraded.

  2 - The host stack and API has been upgraded.

  3 - AFAIK, the Internet service the host uses is upgraded
      - which I think means all routers in that network and
      its ISP need to be upgraded, and I guess sufficient
      routers in the DFZ between the ISP used by both hosts.

  4 - Also, I think there are some upgrades required in
      DNS servers.

BTW, I am not sure why you reference LISP in your I-D.  In what ways
does your system resemble or differ from LISP-ALT, for instance?  You
don't mention ITRs and ETRs.

I only read your draft enough to be convinced it wasn't viable, for
the reasons I described.  I assume that you are somehow generating a
larger global address space of some kind than is possible with 32
bits.  However, I don't see this clearly documented in your I-D.

Your I-D starts with some broad analogies, then some goals and
definitions of terms.  Then there are a list of extensions to
existing protocols, a new type of IP header, I think, to replace
IPv4, and then there is mention of a "LISP" header.  In section 6 I
think we get some idea of how you intend your system to work:

   1. The client queries the DNS server; the hIPv4 stack notice that
      the local and remote RLOC doesn't match and therefore must use
      the hIPv4 header for the connection.

but I haven't been able to fully understand it.

Does this mean that every connection involves identifying a host via
its DNS name?  If so, then I guess your system wouldn't support using
an IP address to identify a host.  A single 32 bit IP address clearly
isn't enough, so I guess the new addressing arrangement means that a
host is defined by a 32 bit RLOC address and a 32 bit address which
only identifies an actual host within the scope of a namespace
specific to that RLOC, or to a number of RLOCs in the same AS.

> And

OK, but I don't see how you can motivate people on an entirely
voluntary basis to adopt a new scheme, with the new kind of address
space only accessible from other systems which have already upgraded.

It is the same problem as with IPv6:  For most people, an Internet
(and the IPv6 network is a separate Internet from the IPv4 one) is
only of sufficient value to warrant not using their current 100%
connectivity Internet when it connects to 100% of the hosts they want
to communicate with.  For most people, this means 100%, or very close
to 100%, of hosts in the world.

> create a demand to have it upgraded, 

You haven't described how mobility would be implemented, nor why it
would be attractive to large numbers of people if it only worked with
the subset of hosts which had upgraded applications, stacks, Internet
connections etc.

> also the OS vendors needs something to create a need for
> upgrades...

But no-one but a few adventurous technical people will want the upgrade.

> per AS. Control plane issue is not that hard to improve, similar has

I think you are describing some kind of change to the FIBs, RIBs and
BGP implementation of all DFZ routers.  That would be really hard to
have implemented, unless you had quite a few years notice - as I
think we do with IPv6.

*Maybe* before introducing the scalable routing system we will be
able to upgrade the DFZ routers, in a less dramatic manner, such as I
suggest here:

  http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw-01

which is a change to the FIB and to route processor task of the
reconstructing the original packet in order to generate a Packet Too
Big message.  But this involves no changes to the RIB or BGP
implementation.

> addressing scheme that is broken.

That is one way of defining the problem.

Another is that the addressing system is fine (apart from 32 bits not
being enough for the long-term future in IPv4) and that the routing
system isn't up to the task of a hundreds of millions of networks
changing their point of attachment dynamically.

I think that any routing scaling solution which involves changing
hosts and applications is never going to be adopted widely enough,
fast enough, on the voluntary adoption basis on which we rely, to
solve the IPv4 routing scaling problem in an acceptably short time.
(Unless of course the IPv6 scaling problem is solved and for some
reason I can't imagine, pretty much every current Internet user
decides they want to upgrade their host stacks and applications to IPv6.)

> add this to the draft, have to think about it for a while...

OK - please contact me offlist and I will make a home for your
presentation and any other files you would like to make available.

  - Robin

---

From: Patrick Frejborg <[email-masked]>
Date: Mon, 2 Mar 2009 12:07:47 +0200

Hi Robin

> socket" applications.  Can you explain this and provide some examples

A raw socket is having direct access to the network layer, therefore
it should be aware of the new header, that is the RLOC and EID fields

Here are some explanations about raw sockets
http://msdn.microsoft.com/en-us/library/ms740548.aspx
http://en.wikipedia.org/wiki/Raw_socket

Not sure but suspect that at least ICMP, PING and IPsec uses raw sockets

About other sockets, see
http://en.wikipedia.org/wiki/Berkeley_sockets

>  1 - The application has been upgraded.
Nope, here is the trick. The application uses sockets API when setting
up the connection. So the stack needs to be backward compatible
towards the application but when the stack is assembling the datagram
it needs to do it in the new way. It is actually the stack that is
doing the map&encap, sort of.
No changes to the application, unless it uses raw sockets. If the
application uses stream or datagrams sockets no need to change the
application.

>  2 - The host stack and API has been upgraded.
Correct, the stack has been upgraded, RLOC and EID needs to be defined
so that raw socket applications can access these new fields

>      routers in the DFZ between the ISP used by both hosts.
Nope, no changes to the network - for a packet to get routed the IPv4
headers destination IP address is used. But we need a new element at
the destination AS (remote RLOC domain), that is the LISP Switch
Router. Actually, this doesn't need to be a router, it could be a
server attached to the network doing the several steps I described in
the draft

>  4 - Also, I think there are some upgrades required in

Yes, DNS and to distribute the local RLOC identifier to the host
extension is needed to the DHCP. ICMP needs extensions as well. A lot
of work and drafts are needed to get the details defined, first we
need a blue print covering the framework. This proposal is not a
network only issue, it goes through all disciplines

> don't mention ITRs and ETRs.
Without LISP teams work and spreading the message I wouldn't be
writing this now. Run into LISP in Barcelona Jan 2008 and that
presentation changed my way of thinking. But since the LISP team has
defined that the host must be untouched I can't say that this proposal
is a LISP solution, but what I'm doing is that LISP gets pushed to the
edge by implementing the map&encap in the host's stack - and the
applications will not be aware of the changes. LISP-ALT is not needed
if we add the RLOC identifier to the DNS records. And the network gets
a lot simpler. Also on the edge (hosts) we have the most CPU
resources, but the other side of the coin is that it is not a network
only issue anymore.
That's the reason, the LISP people is part of the draft though they
don't know about it.

> but I haven't been able to fully understand it.

Sorry for my bad writing, I have time constraint and I can work on it
whenever I can find time - this is not my primary task

> specific to that RLOC, or to a number of RLOCs in the same AS.
When this is fully implemented every AS can have its own IPv4 address
space, except an IPv4 address block (Global RLOC Block, GRB) that we
need to assign to identify the AS.
Since the AS identifier (RLOC identifier) is only distributed between
the AS we can have overlapping IP address blocks as long they are not
connected to the same AS. So if a SME in Finland is assigned an IP
address block 192.168.1.0/24 the very same IP block can be assigned to
another SME in Australia, the US, France, etc because most likely the
Finnish service provider will never be present in those countries. If
a global service provider is used, there could be some more
restrictions but the global SP most likely uses BGP in its network
anyway and thus the global SP will have several AS (and RLOC
identifiers) anyway. So this draft enables that we can a hierarchical
IPv4 addressing space. RLOC identifies the AS (how to route to the
destination AS) and once we are there we look into the local RIB in
order to find the final destination.
It is like traveling,  first you decide which Times Square you are
going to - London, New York, Sydney or Hong Kong. Then order a air
ticket to e.g. Hong Kong, at this moment  I don't care about the "RIB"
of  Hong Kong but once  I get through the customs I get the local map
(RIB) to find a route to Times Square.

Having similar structure to the IPv4 addressing scheme, that is that
the DNS returns a two level A-record: the IP address of the AS and the
IP address of the final destination.

If we reserve, let say, 1 million IP addresses for the GRB we can have
about 1000000*(4,294,967,296 -1000000) addresses, good enough. And the
beauty is that the forwarding plane is already in place and by making
changes to the stack and keeping the socket API intact there is no
need to have a major forklift upgrade. And the DFZ gets smaller, in
the end of the day you have your local RIB and from the global only
the GRB prefixes

> space only accessible from other systems which have already upgraded.
If my host is using the legacy stack and though DNS returns RLOC info
for the destination my host should use the IPv4 scheme - and vice
verse.
If my host is using the hIPv4 framework and DNS returns RLOC
information I can use the new framework though the old network is
still in place.
Here is a smooth transition.

> the subset of hosts which had upgraded applications, stacks, Internet

Please have a look on these two proposals
http://nms.lcs.mit.edu/papers/e2emobility.pdf
ftp://ftp.cs.wisc.edu/paradyn/papers/Zandy02Reliable.pdf
Both proposals need changes to the stack but since this proposal
requires changes to the stack here is golden opportunity to take
mobility to the next level

Hope this help to understand what I have been trying to write in the draft

And we should a very skilled specialist onboard to have a look on the
proposed changes for the stack and socket API, I admit that I do not
have enough skills since my background is networking. But since the
rocks and racks (Zandy02Reliable.pdf) are able to cheat the
application about change of the underlying IP address there should be
a chance that this actually could be implemented. That is, no code is
available, this is an idea that I find interesting

-- patte

---

From: Robin Whittle <[email-masked]>
Date: Mon, 02 Mar 2009 23:36:24 +1100

It will be a while before I have time to read and respond to Patte's
latest message.

He sent me a PPT file with detailed diagrammatic explanations which
look like they would be essential for understanding his proposal:

  http://www.firstpr.com.au/ip/files/PF/

   - Robin

---

From: Patrick Frejborg <[email-masked]>
Date: Wed, 4 Mar 2009 08:25:36 +0200

> socket" applications.  Can you explain this and provide some examples

Uh-oh...I now realize that I haven't spent enough time on this topic,
everything about raw sockets in the draft is just garbage...I'm
embarrassed, apologizing for the low quality.  Thanks for pointing out
this!

So I'll clean up the crap by adding a new section,  "Affected
applications and implications" covering the following topics

1. Raw socket, the most common I guess is the winpcap that is
accessing directly the network layer and bypassing the socket API so
that wireshark can capture the packets in detail

2. Mandatory changes to get the framework up and running
- DNS: RLOC extension needed for A records
- DHCP: new option needed to distribute the local RLOC to the clients

3. Applications that transport IP addresses in the payload and need to
transport RLOC identifiers to establish connections between RLOC
domains. Most of these applications have severe issues with NAT and if
we can reduce the usage of NAT the applications will be easier to
deploy
- SIP and SDP
- Mobile IP
- IPsec AH
- RSVP
- ICMP notifications
- other?

4. Applications that will function with FQDN but sometimes  IP
addresses are used instead, such as ping, traceroute, telnet, etc
We need a new CLI syntax to call the new RLOC socket API, perhaps
<EID:RLOC> is a suitable syntax, e.g, "ping 10.2.2.2:172.16.0.5" when
checking if host 10.2.2.2 is alive in RLOC domain 172.16.0.5

-- patte