Re: TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03

[Geoff Huston <gih@apnic.net>]

For some reason this post of Erik's got caught by the list manager.

The list manager software evidently saw the pattern of the words
"change" and "adres" (spelled correctly of course) in the body of the
message and tried to execute the message as a list command. Too
clever by half if you ask me!

 Geoff




>Message-ID: <43FC8611.9050209@sun.com>
>Date: Wed, 22 Feb 2006 07:41:05 -0800
>From: Erik Nordmark <erik.nordmark@sun.com>
>To: Olivier Bonaventure <Bonaventure@info.ucl.ac.be>
>CC: David Meyer <dmm@1-4-5.net>, marcelo bagnulo braun <marcelo@it.uc3m.es>,
 >       Shinta Sugimoto <shinta@sfc.wide.ad.jp>, shim6@psg.com
>Subject: Re: TE & SHIM6 (was Re: comments on draft-ietf-shim6-proto-03

Olivier Bonaventure wrote:

> I'm not convinced that letting routers change the source locator in
> shim6 would be a good solution. This will add new mechanisms on the
> routers, force them to maintain some additional state and could lead to
> a NATification of IPv6.

Shim6 already allows the shim to change what goes in the adress fields
in the IPv6 header, but since this is undone by the shim at the
receiving end, it doesn't have the downsides of NAT. Thus I don't see
having the routers rewriting what goes in the IPv6 address fields (for a
packet which has IPPROTO_SHIM6) as leading no more NATs.

> Despite this, I have the impression that the IETF did not consider
> entreprise or ISP networks when developping shim6. The basic assumption
> has been that hosts perform all decisions related to shim6 autonomously
> - host select the source and destination locators
> - host check the availability of the path and switch to another one in
> case of problems

I think the multi6 and shim6 WGs did consider site multihoming i.e. a
site where the host endpoints live. (It didn't consider a transit ISP
being multihomed; only traffic that terminate in the site was considered.)

One could argue that the IETF work hasn't taken concerns like traffic
engineering into account. But apart from Jason's concerns, which
resulted in at least being able to carry preferences end-to-end, we
haven't seen much in terms of TE requirements. (And everybody seems to
agree that multiple PA prefixes means that the TE possibilities are
different than in the single prefix + BGP that is the norm for
multihoming in IPv4.)

One might ask why all the pieces of shim6 happen in the hosts and not
also in the routers or other parts of the network. The reason is that in
order to provide shim6 we have to have some changes in the host, in
order to ensure that the IPv6 addresses that the transport protocols and
the applications use are indeed restored at the peer. (The alternative
of a "proxy" shim implementation without any changes on the host seem to
imply an IPv6 NAT as part of the proxy function, i.e., applications that
have problems with IPv4 NATs would most likely have problems with such a
proxy/NAT shim solution.)

Given that both endpoints have to be modified, there is significant
deployment advantage if we don't *require* other changes in the network.
But I think having shim6 work better, e.g., better TE support or faster
failover, by modifying or adding elements in the network is something
that we should consider.

> Letting hosts select paths in multihomed scenarios where a enduser is
> attached to both ADSL and CATV networks is useful. However, if the host
> belongs to an entreprise network, then the managers of the entreprise
> network will probably want to influence the selection of the source and
> destination locators. One possibility to do this would be to tune the
> DNS servers (assuming the hosts perform DNS requests before sending
> data) or define a protocol, used in the entreprise network to perform
> the address selection on behalf of the endsystem. Such a protocol was
> proposed a few years ago :

DNS servers help with destination address selection, in particular if we
can move applications to use DNS SRV records. But it doesn't help with
source address selection.

> 
http://www2.info.ucl.ac.be/people/delaunoi/ietf/draft-de-launois-multi6-naros-00.txt 


Such a mechanism is one of the options. But we have to be careful to not
assume it, because folks want to deploy shim6 without assuming some such
service in the network. For instance, I don't think we should have a
shim6 host by default try to send packets to such a service, since the
service might not be deployed in which case that would just slow things
down.

It also isn't clear to me to what extent a network service which helps
with locator selection fits with the desire of deferred context
establishment; if the TE requirements are such that we want to invoke
such a function (i.e., communicate to the service in the network) before
we send the first packet (e.g., TCP SYN).

It would be interesting to see what's necessary to satisfy the TE
requirements. It might be that the combination of
  - optional but recommended use of DNS SRV records (for initial
destination address selection taking the peer site's priority and weight
into account) and
  - optional router rewriting of locators in shim6 packets
would be sufficient.
It certainly would avoid adding additional message exchanges before
communication starts.

> Letting hosts detect failures is a nice approach in the ADSL+CATV
> environment. In an entreprise network, the border router could receive
> information about the failure (e.g. reception of BGP withdraw) and
> inform the endsystems in the network.

The host has some knowledge (based on observing the bidirectional
traffic, whether done by the transport protocols or by the shim itself)
which the border routers do not passes (the routes could be asymmetric
etc), and the border routers has the BGP information which the hosts do
not possess. Thus ideally we'd like to combine this knowledge.

One way to do this is to have the border routers somehow signal the
hosts. But I'm not sure whether an explicit signal message (ICMP error?)
requires some security between the border routers and the hosts in the
site; the hosts today have no idea of the identify of the border routers.
A way to implicitly convey this is instead of rely on (border) router
rewriting of the source address field.
I don't think we  understand the tradeoffs between those, and any other,
approaches.

> I think that shim6 will have to consider issues that arise when
> thousands of multihomed hosts are in the same entreprise or campus network.

What do you see as additional requirements?
As the shim is currently specified the worst-case message overhead for
the shim is small. (With deferred context establishment some number of
packets will be exchanged between the pair of IP addresses before the
shim does it 4 packet setup exchange, and failure detection has close to
zero extra packets when the ULP traffic is bidirectional).

It is somewhat inefficient to have thousands of hosts each independently
detect that e.g., their address in prefix P1 no longer works. Which is a
reason (in addition to TE) why some explicit or implicit signal from the
(border) routers would be interesting.

    Erik