Re: [rrg] hIPv4-05: new header

[Robin Whittle <[e-mail]>]

Hi patte,

You wrote, in part:

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

Here in Australia, certain prefixes such as 0438 xxx xxx are cellphone
numbers for the carrier Telstra while others such as 0499 (a guess) are
for another carrier such as Optus or Vodafone.  So to do number
portability, the call to some 0438 xxx xxx number can't be connected to
"an exchange which handles Telstra's mobile prefixes", or "the Telstra
exchange for 0438" as it was the case before number portability -
because maybe an 0438 number is now handled by Optus.  Some years ago
when I looked at how number portability worked, I concluded it was
really ugly - with cached database lookups occurring all the time.  I
recall it looked like a hack, which was demanded by regulators.  This
puts up the cost of all calls, but I think it is probably worth it to
increase competition by means of people being able to keep their numbers
when they choose another carrier.

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

Whatever the difficulties with SIP, consider doing it with CCS7
exchanges which were never designed to do anything of the sort.


> 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

I am not following this, but it is late and I am in the middle of GLI-Split.


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

I was just indicating that MPTCP can't be of any help to existing
applications unless they are radically (I guess) rewritten to use MPTCP
- and then to use the hIPv4 version of MPTCP which I guess would be
needed to handle destination hosts with hIPv4 addresses.

  - Robin