Re: [rrg] hIPv4-05: new header

[Patrick Frejborg <[e-mail]>]

Hi Robin

On Mon, Feb 15, 2010 at 3:12 AM, Robin Whittle <[e-mail]> wrote:

>
> 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.
>
Ok, will have a look on that one

> 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:".
>
Yes, if the destination host is in the same realm - use IPv4
(regardless if the host is upgraded or not)
 If in another realm and the destination host is upgraded - use extensions

> I am trying to work on GLI-Split at present, so I won't try to think
> about your proposal more detail right now.
>

Ok, fair enough

>>
>> 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.
>
If you look a little closer there is a hierarchy: country code, area
code and subscribers

I also agree about the admin nightmare, I had the opportunity to do
SIP-I testing with a MVNO and got a look under the hood. It is
definitely not that straightforward when you setup things, including
IN servers.....now when reflecting over the IN-server solution it
starts to have a lot in common with a mapping database in a CES
solution....

With hIPv4 the admin burden changes, the RIRs do not to take care of
the PA-addresses anymore - as long as the PA-address spaces are
defined then it is up to the ISP how they use them internally.
PI-address admin work doesn't go away, it could have more issues than
today - depends what policies are defined by the RIRs


>> 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

I don't see why you would need to rewrite applications for hIPv4 or
MPTCP - both are actually still IPv4 compatible. But of course some
applications will suffer such as IPsec and SIP - SIP is easier to fix
since it can accept extensions, IPsec is much harder but most people
have (or have plans) migrated to TLS based VPN solutions for remote
access. The LAN2LAN IPsec will suffer, that's for sure. But something
has to be sacrificed, think what ever is done, you have to give up
something.

-- patte