Subject: [RRG] SHIM6: portability, ULAs, mobility etc.

From: Robin Whittle <[email-masked]>
Date: Fri, 03 Aug 2007 12:14:01 +1000

Thanks Marcelo for helping me understand SHIM6, in the thread "On
the Transitionability of LISP":

>>              SHIM6  Six/  Mobile  LISP-   LISP-   eFIT-  Ivip
>>                     One   IPv6    NERD    CONS    APT
>>
>> Address
>> portability                       Y       Y       Y      Y
>>
>> Multihoming   Y     Y             Y       Y       Y      Y
>>
>> Mobility                  Y                              Y*
>>
>> IPv4 too                          Y       Y       Y      Y
>>
>> No host                           Y       Y       Y      Y*
>> changes
>
> Just to point out that:
>
> Shim6 can support address portability, if you use portable
> identifiers, such as ULAs. No need to change anything in the shim6
> specs to support that.

My understanding of Shim6 is not ideal, but I don't know how this
could work.  How could host A send a packet to host B in the first
place if host B had a ULA address?

> Shim6 can be used as a RO mechanism for mobility, (it does not
> provides mobility anchor point capabilities, though)

I assume "RO" means Router Only.  I can't imagine exactly how this
would work.  Can you give an example?

> Shim6 can easily support v4 locators (but not v4 identifiers) (the
> NAT traversal capabilities would need to be worked out, but we are
> discussing about that)

Shim6 is therefore not of any help for IPv4 hosts trying to communicate.

> I don't know what kind of problem being solved is "No host
> changed" though... why didn't you include a line about "No router
> changes"? ;-)

I agree that no router changes is a definite benefit of SHIM6.
Likewise, along with Six/One, the lack of tunneling and the increase
in packet overhead, MTU and fragmentation limits etc. is a major
advantage over LISP/eFIT-APT/Ivip etc.

However, I am thinking about 99.9% of today's Internet users over
the next five to ten years.

> However, the main limitation of shim6 is about traffic
> engineering, that you seem to have missed. Shim6 do provides host
> enforced TE capabilities, but does not provides router enforced TE
> capabilitis, which seems to be a desired feature. (OTOH, Six/One
> seems to provide exactly that complementing Shim6)

I was looking at the bigger picture of helping the Internet as most
people use it today keep operating while a new router-based (a small
subset of routers) architecture is progressively introduced to limit
the 220,000 and growing load of prefixes on all the DFZ routers.

Shim6 and Six/One are not solutions to that problem.  They may well
be solutions to the long-term architectural problems of the Internet
*if* most users adopt IPv6.  I can't imagine how this would occur in
the next ten or fifteen years.

I know some people feel very positive about IPv6, but I find it hard
to be enthusiastic.

   The address is so long that all the headers are bloated.  Surely
   64 bits would have been enough, though this probably wouldn't
   support the innovative use of the many address bits which I think
   is central to Six/One.

   The whole thing is a separate system which can't simply be
   adopted as an upgrade, to replace IPv4.  If the network
   connectivity, protocols and interface to the operating
   system required a major switch, but could then fully
   support existing IPv4 communications as a subset of
   IPv6, then I think it would be better.  Instead, the
   host has to run two stacks and the hapless operating
   system and applications need to deal with them both,
   making tricky decisions.  I admit that I don't fully
   understand all the implications of dual stack on applications
   and on users, but from what little I know, it is messy and
   not at all seamless for users.

   The long addresses lead to much more work in the FIB
   of routers.  Likewise they lead to longer messages and bloated
   state everywhere.

99.9% of users don't know what IPv6 is and 95% wouldn't recognise
the term "IPv4".  They just want to use their computers and there is
no way of encouraging or forcing them to install new operating
system software, new applications or to get IPv6 connectivity by
some means.  They don't need to do this because every important
website and service is available via IPv4, and no-one would put an
important site or service only on IPv6 - unless it was only
important to a group of users known to have IPv6, such as perhaps 3G
cellphone users.

I think IPv4 will be the primary system for years to come.  I think
some LISP/eFIT-APT/Ivip system will be introduced and will enable
most of the address space to be closely populated with active users.
 I think this will keep IPv4 going for the next decade or two as far
as address space is concerned.  NATs are ubiquitous and will remain
so, unfortunately.

The pain of incremental change to something different such as IPv6
may forever be worse than the pain of incrementally investing in
more workarounds for IPv4's difficulties.  A few decades later, we
will look back and say "It would have been much easier to make
everyone switch to IPv6 or whatever in 2009 . . . ".

No doubt the IPv6 debate has been done to death and this is not the
place to rehash it.  I am just trying to explain why I don't think
it is such an elegant alternative, so people on this list understand
why I think most users will not be tempted to adopt IPv6 any time
soon.

  - Robin

--
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: marcelo bagnulo braun <[email-masked]>
Date: Thu, 2 Aug 2007 22:57:25 -0400

> place if host B had a ULA address?

i assume that hosts will have (routable) locators bsides the ULAs  
that will used as ULIDs.

So, the communication will flow using ULAs as ULIDs and PA addresses  
as locators. Assuming that all applications use identifiers, you can  
renumber the locators without impact or need for manual reconfiguration.

> I assume "RO" means Router Only.

No, RO means route optimization

> I can't imagine exactly how this

this is long. but it is described in detail in http:// 
www.watersprings.org/pub/id/draft-bagnulo-shim6-mip-00.txt

> Shim6 is therefore not of any help for IPv4 hosts trying to  

shim6 requires host to be updated to benefit from it.
So shim6 can be used in v4 sites (i.e. sites wihtout v6  
connectivity), but the hosts will need v6 addresses to be used as  
locators. Please note that it is perfctly possible that the hosts  
involved have no v6 locators.

> the next five to ten years.

not sure what do you mean about this....

> the 220,000 and growing load of prefixes on all the DFZ routers.

not sure i buy that one. 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)

> Shim6 and Six/One are not solutions to that problem.

by definition thy are not, since you are specifically constraining to  
router based solutions. It is perfectly ok to explore this part of  
the solution space, though

> They may well

i agree that deployability is the crux of the problem

i agree that shim6 deployment is a great challenge

not sure if other approaches will make this easier though

For instance, i would like to understand the incentives for ISPs to  
deploy anycast itrs

> I know some people feel very positive about IPv6, but I find it hard

i certainly agree that supporting v4 identifiers is a great  
advantage, but there are others deployment issues to be dealt with.

regards, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Fri, 03 Aug 2007 21:36:14 +0300

> [...]         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)

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

- Christian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Aug 2007 11:37:44 +0200

> (as in the case of mobile phones).

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.

     Brian

---

From: Robin Whittle <[email-masked]>
Date: Wed, 08 Aug 2007 01:00:45 +1000

Hi Marcelo,

I am responding to your message of 3 August:

  http://psg.com/lists/rrg/2007/msg00234.html

> i assume that hosts will have (routable) locators bsides the ULAs that
> will used as ULIDs.
> 
> So, the communication will flow using ULAs as ULIDs and PA addresses as
> locators. Assuming that all applications use identifiers, you can

I still don't see how a correspondent node CN can establish
communications with a node PN with a portable address, by CN having
a copy of the ULA address of PN, but without knowing at least one of
PN's current globally routable, (global unicast) IP addresses.

> this is long. but it is described in detail in
> http://www.watersprings.org/pub/id/draft-bagnulo-shim6-mip-00.txt

This is not long.  I think it relates to Shim6 and Mobile IPv6
working together.

In my chart I was suggesting that Shim6 can't provide mobility on
its own, that Mobile IPv6 can, and that Ivip can too, with certain
extra things:  Firstly there needs to be one or more TTRs
(Translating Tunnel Routers) and with a Mobile Node (with suitable
software) with a tunnel to that TTR which acts rather like a Home
Agent, together with some external system to control the mapping and
so direct Ivip's ITRs to send packets to one TTR or another.

I explain this in:

http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-arch-00.html#anchor81

The total mobility system which Ivip could provide has three
fundamental benefits over Mobile IPv6:

1 - It works just the same for IPv4.

2 - The ITR network tunnels packets to the TTR, and the TTR is
    chosen by the Mobile Node to be close to the Mobile Node.  So
    packet paths are close to, or actually, optimal.

3 - The correspondent host needs no new software.

> So shim6 can be used in v4 sites (i.e. sites wihtout v6 connectivity),
> but the hosts will need v6 addresses to be used as locators. Please note
> that it is perfctly possible that the hosts involved have no v6 locators.

OK - but Shim6 is not any use to ordinary IPv4 hosts that the
end-user is unwilling or unable to upgrade in any way.

I responded in another message "Upgrading user device software for
multihoming or solving ROAP" about why I think that for IPv4 at
least - as used by virtually all end-users now and in the five year
timeframe I assume the new architecture will be deployed within -
host changes are out of the question.

> router based solutions. It is perfectly ok to explore this part of the
> solution space, though

Sure - but they are only solutions to IPv6 problems.  Hardly anyone
uses IPv6 and the difficult task is to find a solution which works
for IPv4, and ideally works in a similar way for IPv6 too.   LISP,
eFIT-APT and Ivip all should work for both IPv4 and IPv6, but the
extra header lengths with encapsulation are 20 bytes longer in IPv6,
which makes any such tunneling architecture less efficient with IPv6
than with IPv4.

The great benefit of Shim6 and Six/One is that there is no tunneling
overhead.  However, does Shim6 use an extension header on some or
all packets?  That would be some overhead.

If so, how does Shim6 tell the application or upper layer protocols
to make packets which are shorter than otherwise would be the case,
so that the addition of the extension header doesn't cause the
packet to overstep some MTU limit?

> i certainly agree that supporting v4 identifiers is a great advantage,
> but there are others deployment issues to be dealt with.

I will write more in another thread about deployment scenarios.

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