Re: [RRG] Elegance and the rejection of SHIM6 host-based multihoming

[Robin Whittle <rw@firstpr.com.au>]

Hi Iljitsch,

You wrote:

>>>> But how could an application protocol know it is running over SHIM6
>>>> and therefore decide it doesn't need to use keepalives?
> 
>>> Applications don't need keepalives.
> 
>> I am confused by this but it is probably not worth pursuing.
> 
> :-)
> 
> Life is easier if you just go with the flow and don't want to control
> everything. As an app, when you have data, just send it. Either it will
> get there or not. Having sent keepalives doesn't make the former more
> likely or even accurately predict the latter.

I understand keepalives are there for the benefit of NAT - to keep a
session in the NAT cache even if there is no actual data to be sent.

>> With Ivip, there would be no such delay or
>> extra traffic testing connectivity etc, because the end-user
>> provided multihoming monitoring system would already have detected
>> the problem and fixed it already by changing the mapping.
> 
> How does ivip know I have an IMAP session that has been idle for 20
> minutes?

Ivip's heuristics have already classified your traffic pattern and
scored it in the 99th percentile in the "advanced technology geek"
dimension.  Such folks are never separated from their IMAP server
for long.

The last 20% of: http://psg.com/lists/rrg/2008/msg02585.html has a
description of how an end-user network would probably hire a company
to continually monitor reachability of their network, and make
decisions about changing mapping.


>> I still prefer the idea of the end-user having their own,
>> potentially highly customised, outage detection system with their
>> own preferred decision making system to restore connectivity with a
>> single action
> 
> Right, that's exactly what REAP does.  :-)

OK - I see this is your work with Jari Arkko and others, which I
will read:

   http://tools.ietf.org/html/draft-ietf-shim6-failure-detection-13
   http://www.shim6.org/47120443.pdf

The approach I describe for Ivip is very different, since it does
not work with hosts which are part of any communication.  That may
be a problem in terms of it not detecting every possible constraint
on packets being sent between two communicating hosts.  However, I
think it scales a lot better than having thousands of hosts all
doing reachability testing with one host.

If the barrier to reachability is close to the sending host and its
ITR, rather than the destination ETR, it is probably not much good
tunneling to an ETR in another ISP, since at the sending host's end,
the encapsulated packets would probably follow the same path.  This
is not absolutely true, of course.  There would be some outages
which a purely host-based or ITR based reachability system would
detect and successfully solve by selecting a different destination
address or ETR address - and which would not be detected, or should
not be detected, by the separate scheme I propose.


>>> Yes, that is correct for shim6 is it's currently defined. But you could
>>> easily (ok, maybe not so easily) add a mapping system to shim6 and then
>>> it COULD support all of this.
> 
>> Then it wouldn't so much resemble SHIM6 as Ivip's option for ITR
>> functions in the sending hosts!
> 
> The shim6 control messages could be reused with very few changes.

Maybe - I am keen to pursue a system which does the work in the
network, and leaves the hosts alone, except for consenting hosts
which want to integrate an ITR function in themselves.


>>> Get over it, this is a result of choices made in the IPv6 design a long
>>> time ago, regardless of the presence of shim6.
> 
>> But those choices only make sense if SHIM6 is widely adopted.
> 
> Many hosts that run IPv6 will also run some kind of IPv4, so that means
> that they'll have at least an IPv6 link local address, a global IPv6
> address and an IPv4 address. So apps must be prepared to cycle through
> all addresses and know which one to use for referrals anyway, regardless
> of whether the host has multiple global IPv6 addresses.

You are saying that applications will have to change to work with
IPv6.  But I am saying no-one uses IPv6 much because many
applications, printers and other devices don't work with it, and
because there is no-one much home on the IPv6 Internet yet.


>> rather than giving up on this and expecting hosts to
>> maintain reliable communications with other hosts in an environment
>> of multiple IP addresses, any one of which could become unusable
>> without prior notice.
> 
> This is current practice today because DHCP servers may give you a
> different IPv4 address at any time. When that happens applications like
> Apple's Mail simply reconnect to the server without interrupting the
> user's work.

In practice, I understand DHCP servers typically don't give out a
different IP address for no good reason.  I understand many DSL
customers often have the same IP address for months or maybe years.

It is one thing for DHCP to be capable of giving a host a different
IP address from time to time.  It is another to try to get everyone
to change to an Internet in which multihomed hosts have two or more
addresses, one of which could fail at any time, with the host stack
and applications being expected to work with the other one.


> Other apps need some kind of manual restart, though.

OK.


>>> Since when are referrals reliable in the first place? They're a big, big
>>> mess and the IETF hasn't even considered starting a cleanup effort.
> 
>> 1 - A specifying C to B by way of C's DNS name.
> 
> That doesn't happen in practice because home users have no control over
> their DNS names.

Yes, and C doesn't necessarily have a DNS name.  NAT makes a mess of
referrals, of course.

>> 2 - A specifying C to B by way of C's potentially multiple
>>    addresses, of which A may only know one.
> 
> Current protocols are unable to do this.

Yes.


>> Both are a lot more complex than using a single IP address - and for
>> any applications which use a single IP address now, there would have
>> to be significant application and protocol changes to handle either
>> of the two options above.
> 
> Yes. But like I said, hosts have multiple addresses and/or don't know
> their own address because they're behind NAT today so there is no easy
> way out.

I agree.


>>> There is plenty of IPv4 address space for the forseeable future, it's
>>> just not distributed evenly. Redistribution efforts haven't had
>>> spectacular results in the past, and I don't expect them to be succesful
>>> enough in the future to continue to meet current demands after we run
>>> out of free IPv4 address space.
> 
>> Past redistribution attempts, of which I know little,
> 
> "Please return unused addresses or at least sign the ARIN contract".
> 
>> were not motivated by the increasing financial impetus to gain 
>> precious IPv4 space
> 
> I believe that freeing up considerable amounts of address space is more
> expensive than the price the big address users are willing to pay so if
> a market is allowed it will only work for small blocks where there isn't
> much of an issue in the first place.

The big players already have vast tracts of IPv6 space - but it is
currently no use for creating services which customers want to pay
for.   There is only one kind of address space which has any
commercial utility at present - IPv4 space.  The big ISPs may not
want to pay X dollars or get the space in smallish chunks compared
to what they got for lower costs in bigger chunks in the past.
However, until most end-users have IPv6 connectivity, stacks and
applications, IPv4 space is the only kind which can be used for
saleable services - not counting cellphones and customers in captive
situation where the only available ISP only offers IPv6, which would
be a rare or non-existent situation.


>> so I expect there will be considerable business and
>> technical innovation in making the most of the increasingly
>> fragmented and populated IPv4 space,
> 
> If the big users aren't going to string together lots of small blocks
> when they can't get big blocks anymore the fragmentation won't increase
> beyond what's already happening now.

I can't predict what will happen - but I think there is a long way
to go before IPv6 space can be used for a saleable Internet service.


>> The most obvious technical solution is a core-edge separation scheme
>> which can slice and dice address space down to single IP addresses
>> in a scalable manner: LISP with PTRs or Ivip.
> 
> No, the most obvious technical solution is RFC 2460. But apparently
> obviousness isn't much of a consideration.

If "technical" means not worrying about unfortunate details such as
users needing to communicate with all other users, all users being
on IPv4 and IPv6 not being able to inter-operate with IPv4, then I
agree.


> I'm fine with having host level mobility in a map and encap scheme as
> long as there is a hierarchy, I don't want to see 3.7 billion /32s at
> the top of the addressing hierarchy.

It may well come to that.

The barriers to mass migration from IPv4 are extraordinarily high.


>> I don't have a clear idea about how many DFZ routes constitutes an
>> unworkable problem.
> 
> We cleared the 250k hurdle without too many problems, so I guess we'll
> be ok until around 500k if the growth doesn't happen too fast.
> 
> But big ISPs have lots of internal prefixes, so they may run into some
> limit at any time and start filtering longer prefixes, like Sprint 10
> years ago.

I think this was discussed in the last few months.  I can't see how
an ISP would willingly make itself unreachable to some subset of the
Net rather than buy newer routers.  Such actions would be seized
upon by competitors and the customers would remember it for years
afterwards.


>> Probably there is no clear point where things
>> get unacceptably bad
> 
> Because BGP is a real time system, when you do X and you break it, you
> quickly undo X and it will probably work again.

My guess is that the pressure of rising DFZ routing table numbers
would be felt as having to either buy a new router, or limit the
number of neighbours it has, depending on its RAM, CPU power and
number of non DFZ routes it handles - assuming the FIB is not the
limiting factor.

 - Robin


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg