[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] SHIM6: portability, ULAs, mobility etc.
I am responding to your message of 3 August:
>>> 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?
> 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 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.
>>> 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.
> No, RO means route optimization
>> I can't imagine exactly how this
>> would work. Can you give an example?
> this is long. but it is described in detail in
This is not long. I think it relates to Shim6 and Mobile IPv6
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:
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.
>>> 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.
> 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.
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.
>> 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
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?
>> 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 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
>> to be enthusiastic.
> 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/
to unsubscribe send a message to email@example.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