Hi Patrick,
Thanks for your reply, in which you wrote, in part:
>> 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
I agree.
>> 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.
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
> 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.
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.
> 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,
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.
> 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
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.
>> 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.
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.)
>> 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...
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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
