Hi patte, In the "hIPv4 critique (draft = final)" thread, you wrote:
> seems to be some misunderstandings in our dialogue, will try to > explain in more details Sorry - I misunderstood your proposal for a new 40 byte header format: http://tools.ietf.org/html/draft-frejborg-hipv4-05#section-6 I had thought that this header began with a different 4 bit Version code, but I understand it uses exactly the same Version bits as the IPv4 header. I now understand you are defining a new 20 bit header to follow the IPv4 header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|P|S|VLB|L| R | Protocol | LH Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Endpoint Locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Private Locator Referral | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ which would have an 8 bit protocol number assigned from: http://www.iana.org/assignments/protocol-numbers/ so the protocol field in the IPv4 header would contain the number for this hIPv5 header. I think this could be done. I guess that DFZ and other routers could handle the packet OK - can any router experts confirm this? But please see (msg05993) for mention of the idea that traffic packets which don't use UDP or TCP headers would run into difficulties with (or at least, not make best use of?) sets of routers using ECMP/LAG. I am referring to the [Diff2] of your 05 draft to see how your proposal has changed with the new header arrangement. As long as you can be sure that the new packet format is only sent to hIPv4 hosts, I think you should be able to do whatever you like with it. As I understand your proposal, you are relying on some kind of DNS mechanism for this: "How a hIPv4 session is established follows:". I am trying to work on GLI-Split at present, so I won't try to think about your proposal more detail right now. >> I don't want to discourage further development of your proposal, but I >> think your version 05 is not at all practical since it involves a new >> kind of packet format. This would require all DFZ and all other routers >> to be upgraded, and upgrades to all the stacks of all hosts which use >> hIPv4. I am sure these requirements would rule your proposal out of >> consideration as a scalable routing proposal, since we can only plan to >> develop something which will be voluntarily adopted on a very wide basis. > > It is a new format but the legacy routers will not see the new format > since to them this is a legacy IPv4 header - the only change is that > there is new protocol number in the IPv4 header. And routers shouldn't > care about that, the packets should stay in the fast path as long as > the header length is 20 bytes. > > The new protocol number is used by the endpoints and the LSR to > distinguish between IPv4 and hIPv4 packets, when the new protocol > number is used the endpoint and LSR knows that after the IPv4 header > there is a shim header and not a transport protocol header. OK. At present I can't see any objection to the new header arrangement, provided it is only sent to hIPv4 hosts. > Nope, the routers shouldn't see it all - the locator header is not > part of the IPv4 header. It is a shim header sitting between the IP > and transport header. Thus the hIPv4 packet stays in the fast lane and > gets routed through the legacy network, the LSR and destination > endpoint will know by the new protocol number that there is an > additional header before the transport protocol OK. >>> About the 32-bit address space, I think it is good enough. In the >>> pre-RRG world it isn't but here at RRG two issues has been discussed >>> quite a lot that changed my world quite radically, that is, the >>> core-edge separation/elimination and the decoupling of >>> identifier-locators. >> >> I think Locator/Identifier Separation is a bad idea: >> >> Today's "IP addr. = ID = Loc" naming model should be retained >> http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html > > Here I disagree, think the HTTP cookie mechanism is great and a > generic model should be created to enhance endpoint mobility. OK - This is an upper layer protocol (ULP) approach to "Locator/Identifier Separation" in which the cookie is the Identifier used in a persistent session. The actual end-point IP addresses then become unimportant. I support this form of "Locator/Identifier Separation" - but not converting the basic IP protocols to such an arrangement. > If the identifier is in the address space you have to use an overlay > solution such as MIP. It matters where you place the identifier in the > TCP/IP model I think with mobility, it is important to minimise the tasks which must be preformed by the MN, and to make it work for IPv4 and IPv6 with ordinary (no-upgrades to stack or applications) correspondent hosts, while generally having optimal or close to optimal paths. The only approach I know which can do this is: http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf >> Still, the 3.7 billion limit on IPv4 global unicast space remains a >> serious long-term problem. The main thing it can't handle is billions >> of cellphones on IPv4. I am not sure it can handle all the homes and >> offices which ultimately want a DSL or fibre or whatever service like >> people get today with DSL etc.: a single global unicast IPv4 address for >> their NAT box, and with which they can port-forward whichever UDP and >> TCP ports they like, since they are not sharing this IPv4 address with >> anyone else. > > Have you ever wondered why PSTN doesn't suffer from this kind of > problem - how can they have billions and billions of landline and > cellphones hooked into the PSTN? > > Over here my cellphone number is mine, I can choose any cellco and my > numbers stays the same when I change cellco > http://www.numpac.fi/index.php?site=127 When I last looked at it, I concluded that number portability in the PSTN is a technical and probably administrative nightmare. I also think it is a necessity, for reasons of enabling competition. But the PSTN was never meant to support such arbitrary assignments of services in the same number range to completely different networks. The PSTN has a variable length addressing system in which the roles of Identifier and Locator are both played by the number itself. The text-name role is played by printed and web-based telephone directories, and dial-up directory assistance. As I understand your proposal, you are plunking an optional 32 bit field to the left (more significant) of the current IPv4 address. So only hIPv4 hosts can work from these new number ranges - but they can also work like ordinary IPv4 hosts in the base IPv4 address range, which has no such extension. There is another approach to what you are suggesting - adding a 32 bit field to the right - making a new addressing system where each existing IPv4 address could "contain" 4 billion of the new kind of addresses. >> I think 64 bits would be fine for a new addressing system. I think >> IPv6's 128 bits is overkill and makes packets too long, and host >> software too complex, since CPUs only deal with 32 and 64 bits. >> >> Anyway, that is academic for now - the best routing scalability >> solutions do not require anything as drastic as new addressing systems, >> and the consequent need to alter all host-stacks and substantially >> rewrite all applications. > > Exactly. > > If you create a two level hierarchy you can preserve the current > addressing scheme and still create a new routing architecture. If you > reserve a 256k/512k/1M address space for ALOC then each ISP can have > their own IPv4 address space for their customers. OK - but only if all the customers have their hosts with hIPv4 stacks and all their applications are upgraded to cope with hIPv4 too. Both of these seem impossible to bring about. > With one IPv4 > address space 1,7 billion users have been able to enjoy the Internet > experience, with e.g. 512k times more IPv4 address spaces we should be > able provide Internet experience for everyone. Yes - and all their pets! > It will have implications though - you can't share routing information > of every prefix with every one - then you would run into overlapping > prefixes. Thus one ISP can have only its directly attached customers > in their RIB, the ISP will not accept any routing information from > other ISPs except their ALOC information - the PI and PA prefixes from > other ISP stays within each ISP's RIB. Also, if I'm running an ISP - > why should I be interested if a certain prefix of another ISP is > installed in my RIB or not (using power, space, cooling and FIB > resources if installed)? For me it is enough that I can find the other > ISP (by the ALOC), send the packets over to that ISP and they will > deal with the local forwarding - it is their problem to route the > packets to the final destination, it is not my problem and actually I > don't care how they do it. The outcome is that the RIB of core-DFZ is > reduced quite a lot, also the amount of paths are suppressed in the > DFZ because the edge prefixes (PA and PI addresses) are aggregated > behind one ALOC prefix. OK - I think I have a rough picture of this. In the future I hope to be able to think about it more, but I would also want to explore options for giving multiple new addresses behind each existing IPv4 address. > This will have implications for multi-homing solutions, but here MPTCP > comes to rescue Since you are proposing rewritten stacks and applications for all hosts which participate in your architecture, you can also require that most or all existing apps use the hIPv4 version of MPTCP to do their own multihoming. However, as I wrote in the above-mentioned (msg05864) I am opposed to this in general, since I think the routing system should handle multihoming and mobility, not individual hosts, much less applications - Robin _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
