[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-shim6-proto-03
Jason Schiller (email@example.com) wrote:
The problem here is not not the multiple addresses, but rather a partial
ID / locator split. As long as DNS contains information about both the
identity of the host and the location of the host then the ID and the
locator are not completely split. This creates the problem of sifting
through DNS, and making the solution non-useful for short lived
sessions. Also, this problem is what is creating the push for provider
independent (PI) IPv6 space to avoid "provider lock-in".
I'm not convinced. HIP provides complete separation between identity and
location, yet it doesn't provide for any more network policy input than
Imagine instead DNS only has knowledge of the identity, say the host
address, local subnetting and a way to uniquely identify the site. The
source host builds a packet and kicks it to the network without the
locator information. The network needs some mechinism to map the site
identity to one or more locators. In this model the source host,
destination host, and DNS system don't care about location. This is left
up to some protocol in the network. On ingress this could be easy for the
source, just pre-pend your routing locator. For the destination there
would need to be some mapping of site ID to one or more locators. The
network could pick the most convient locator for the destination.
So we have a domain name to ID lookup using the DNS, and then be have
some new system/mechanism for looking up an ID and find one or more
locators, and that new mechanism takes network policy into account. Did
I get that correct? Or does the new system also take reachability,
available bandwidth, etc into account?
Has anybody thought about the scaling requirements for this new system?
I would assume one should plan for success, and since the ID/locator
separation will help with renumbering in addition to multihoming, this
probably means that the system should scale to every site in the future
internet using it. (I think during IPng discussion folks were throwing
around 10^12 "networks" as the requirement, with 3 orders of magnitude
We have a system we think can scale to such scales; the DNS, so it is
probably useful to look at how it scales:
- hierarchical name space (and when that breaks down as with .com,
operating the service becomes quite expensive)
This is why I think my above question about what information the
mechanism takes into account is absolutely critical. If it is more or
less static policy (which can be cached for hours) there is a chance
that it can be made to scale.
But we might also need the ID name space to have several levels of
hierarchical allocation to scale the lookup.
But if we need to take into account information that changes more
frequently, I think we're likely to end up with something that has the
same scaling issues as BGP. There is no such thing as a free lunch as
Noel likes to say.
FWIW, once we have the above, we still need a protocol that can provide
the end-to-end locator agility (without creating a large security hole).
So the question in my mind, while we explore the above, is whether we
would do shim6 any differently if we had the above ID lookup system.
(Note that there is nothing in shim6 the protocol that assumes that the
ULIDs are indeed routable addresses; it is merely a convenient way to
deploy things and it doesn't have the overhead of doing some extra
lookups for ID->loc mappings.)
This same site ID to locator mapping protocol could be used by transit
ASes to rewrite the destination locator information and forward the
packet towards the destination at an alternate location. Transit ASes
that don't wich to perform TE can simply forward the packet and do not
require the added site/locator state.
Are you assuming that
1) every packet would carry IDs (in addition to the locators)?
2) that the routers would do some lookups on the ID?
There is potentially a simpler way for routers to influence the
locators, which is just having them do source locator rewriting (as in
Mike O'Dell's GSE.)
Shim6 already allows this on data packets, and maybe we should make
shim6 allow that on its "control" packets as well. *If* we allow this,
and such rewriting is useful, we can get that aspect of GSE behavior
while having the "first, do no harm" security level present in shim6.
I'm not sure this scales any better than de-aggregation as all ingress
routers and any transit routers that want TE will need state to map one or
more locators to every site.
The total size of the policy would be large. But if it is mostly static
then it might be manageable.
We can still do load spreading and primary/fallback with a static
policy; the policy can be expressed akin to DNS SRV records with a
priority (for primary/fallback) and a weight (for load spreading), and
the client of the policy evaluates this.
If you want the policy to change due to dynamic events, even if it is
just based on different policies for different times of day, then things
But this also assumes that anybody that connects is allowed to see the
policy to be able to do the evaluation of what locator to use. That
might run into trouble with existing practices.
An alternative would be to have some TBD mechanism (some new DHCP
option?) for the destination site to distribute its policy (e.g., in the
form of priorities and weights) to all the hosts in the site, and then
use shim6 to express those to every peer that connects to a host in the
Thus at a gross level I see two different ways to factor the system:
A. An ID->loc lookup system which takes some policy into account.
B. An ID->loc lookup system without policy, plus
policy distribution within each end site and host-to-host exchanging
of preferences when they start communicating.
For both approaches there is the question how useful it is to allow
routers to rewrite the source locators.
I know how to build B out of existing components. But B doesn't allow a
transit ISP to express their policy; only the end sites can do it.
On the other hand, I have no idea what the threat model is for A; how to
make a distinction between a legitimate ISP on the path, and an attacker?
Hmm - perhaps we should write this up in an I-D?
I'm sure there are more details to discuss, and I'd really like to
explore this more to determine whether we need to do shim6 differently.
And, from my understanding of approach B, the only open question in my
mind is whether we need to make shim6 allow locator rewriting on its I1,
R1, etc control messages.