Subject: [RRG] Upgrading user device software for multihoming or solving ROAP

From: Robin Whittle <[email-masked]>
Date: Tue, 07 Aug 2007 22:03:21 +1000

I think it is much better and easier to upgrade a few routers than a
lot of end-user devices, to provide multihoming or to solve any
other Routing and Addressing Problems (ROAP).

However, for those IPv6 hosts which can do SHIM6 and multihome in
that way, I think that is an elegant solution - as far as it goes.

In "SHIM6: portability, ULAs, mobility etc."  Marcelo Bagnulo Braun
wrote:

>>> [...] IMHO it is way much harder to update the
>>> routers than updating the hosts. I mean, windows update does it for you
>>> (either you like it or not)

Christian Vogt wrote:

>> I agree.  In most cases, either host upgrades are highly automated and
>> require limited to no user interaction (as in the case with all major
>> operating systems today), or the host time-to-replacement is very short
>> (as in the case of mobile phones).

and Brian Carpenter wrote:

> Exactly. Also, shim6 is self-deploying - it will work if both ends of
> a session are shim6-enabled, otherwise it reverts to plain unicast
> IPv6. It even works if both ends are shim6-anabled, and one end
> refers the other end's ULID to a third party that is not shim6-enabled.
> 
> This means that shim6 will sink or swim on its own merits, and doesn't
> need a Grand Plan.

Maybe the upgradablity of IPv6 user devices can be assumed, but it
seems unlikely to me.  Once "devices" include consumer devices like
web-cams, laser printers, ADSL modems, WiFi enabled iPods etc.
there's no way to upgrade them.

Google finds 10k pages for "IPv6 lightswitch".  I don't think we
want to be downloading operating system upgrades into lightswitches.
 I know many of these devices are likely to be used on local
addresses, and so wouldn't need global unicast IP addresses,
world-facing operating systems or multihoming.  But if I had an IPv6
lightswitch, I would want to be able to SSH to it from any host in
the world.

For IPv4, I think the routing and addressing problems are not going
to be solved by any approach which assumes upgradeable software in
user devices.  There are far too many desktop machines, DSL modems,
RAQ web servers etc. out there which no-one is ever going to add
software too.  No new architecture can afford to be unreachable from
those many devices.

  - Robin           http://www.firstpr.com.au/ip/ivip/

--
to unsubscribe send a message to [email-masked] 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

---

From: [email-masked]
Date: Tue, 7 Aug 2007 10:01:09 EDT

In einer eMail vom 07.08.2007 14:04:36 Westeuropäische Normalzeit  schreibt 
[email-masked]:

Wrt. the above, I am convinced that it is feasable to make inter-domain  
routing scalable (such that 2K  rather than 200 K FIB entries would do) by  just 
enhancing the DFZ-routers. Although the ultimate goal should be a  
one-face-routing protocol instead of the two completely orthogonal designs of  OSPF and 
BGP, that would still be a valuable compromise.
 
Heiner Hummel

---

From: András Császár (IJ/ETH) <[email-masked]>
Date: Tue, 14 Aug 2007 19:50:43 +0200

> lot of end-user devices, to provide multihoming or to solve any other
> Routing and Addressing Problems (ROAP).

Hi, I agree with you, although "few" can only be understood in contrast to the number of end-user devices. :-) Some hundred thousand routers are hardly "few" :-) There is the additional fact that routers are very expensive.

Anyway, routing scalability is a problem in the DFZ routers, so for me it also seems to be logical to solve it there. 

> ...
> Google finds 10k pages for "IPv6 lightswitch".  I don't think we want
>  to be downloading operating system upgrades into lightswitches. I
> know many of these devices are likely to be used on local addresses,
> and so wouldn't need global unicast IP addresses, world-facing
> operating systems or multihoming.  But if I had an IPv6 lightswitch,
> I would want to be able to SSH to it from any host in the world.    
> 

Yes, if the solution was not backwards compatible in some sense. I mean, has there been any solution proposal around which assumes host changes but which would render the legacy hosts unreachable? I think no.

Solution requiring host changes should in each case give an alternative for proxy mode, so that host need not be changed after all.

But I think the question is more fundemantal, whether host changes are feasible or not. Is the host the right place to solve all problems? I think no.

Where is the problem?

In case of host multihoming: The problem is in the host with its sockets. The problem should be solved in the host. HIP solves it in the host, but without the deployment of HIP, most applications solve it in higher layer (e.g. re-connect)

In case of routing scalability: it is in the DFZ routers, not in the hosts. Each router taking part in global BGP routing could face the problem. Therefore, it should be solved in the DFZ routers, or in the routing protocol (generally not run by hosts).

And why do we face routing scalability limiations? Now, that was one very intersting topic in the last RRG meeting. Some people do not agree that is only multi-homing or PI addresses.

There were two other interesting reasons:
- advertising more specifics to do ISP inbound traffic engineering
- advertising more specifics to prevent false origination

So, my question is, do we reliably know which one of the above (or which other) cause is responsible for the FIB increase?
What else could bring operators now or in the future to advertise more specifics?

Do the proposed solutions address all causes? The basic philosophy of ENCAPS and it reincarnations today is to separate DFZ (i.e. Internet backbone) routing from the rest. Are we sure that it will solve the problem? If tier-x operators do advertise more specifics, then probably not. Any opinions?

Kind regards,
András