[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: I-D ACTION:draft-nordmark-shim6-esd-00.txt]
El 02/03/2006, a las 22:42, Erik Nordmark escribió:
In section 2.6 Design Alternatives it is stated
If the identifiers are placed in the DNS using AAAA records, then
lookup for the AAAA record set (to find the identifier) might also
return a list of locators.
another alternative that probably would result in similar behaviour
would be that the identifier is included in the identifier record,
but that the same query that returns the ID record also returns the
locator set associated to this identifier in the additional
Such information would be delivered by the resolver to the shim
process which would store it for when the packet addressed to the
Yes, apart from the point below ;-)
Putting the ids in AAAA records, assuming it can be made to work, have
a performance benefit. Without it, the host has to
- look for an ID RRset
- if none found look for AAAA RRset
- if none found, look for A RRset
This is extra overhead when the target host doesn't have any ID RRs.
If we could put the identifiers in the AAAA RRset in such a way that
legacy IPv6 hosts wouldn't try to communicate with them (due to the
RFC 3484 ordering putting them last in the list), then even for target
hosts that don't have IDs there is no extra DNS lookup.
Yes this makes sense to me
Such a list can potentially be useful to
avoid the ip6.arpa lookup to find the locators. But relying on
means that the reverse lookup from the identifier will only be used
in uncommon cases such as:
o The shim6 context state having been garbage collected too early,
and the upper-layer protocol sends down a packet with a
destination ULID which is a non-routable identifier.
o Application callbacks, referrals, and long-lived application
handles  that are IP addresses.
For this reason it makes sense to be more consistent and always
on the reverse lookup when the context is established.
I fail to understand this point. I mean avoiding extra DNS lookups is
good, since it reduces latency and load to the servers. why do we
want to impose this? just to make sure that the reverse information
is in place i.e. that the reverse tree is properly populated? i think
this is an expensive price to pay for this and i would rather prefer
that those that have the reverse tree poorly populated simply have
problems with the referrals rather than imposing a penalty to all
FWIW it isn't only referrals and the like that would be a problem when
the ID->locator lookup isn't populated; also the case when the shim
discards the context state would not work since there wouldn't be a
way to rediscover some locators once the context state is gone.
My take is that we are doing shim6 and its extensions to gain better
robustness of the network as seen from the communicating applications.
Thus saying that we don't care about robustness by not ensuring that
the id->locators lookup mechanism is populated doesn't make much sense
I agree that we should care about robustness
But my point is that if someone is doing shim and it is using non
routable ids, then he probably cares about robustness and so he should
know that he must properly populate the reverse DNS.
I mean i consider that the penalty of artificially imposing a reverse
lookup when establishing every shim context in order to make sure that
the reverse entry exists, seems an overkill to me (especially because
we will be always paying the cost even once the reverse dns is properly
populated for these id)
There isn't a free lunch here - introducing a separate 128-bit
identifier space provides significant benefits, but also comes with
Yes, but imho we should try to minimize that cost.
Having to do the ID->loc lookup when a referral, call back, lost
context event occurs, is the cost that we really need to pay
Having to do it for every shim context establishment is not strictly
necesary, and imho we should avoid that
About using v4 locators
I think that supporting v4 locators would be very valuable for the
protocol. I would suggest to move this to a separate document and
adopt it. (maybe it could be included in the base spec since it seems
quite trivial to do)
OK. Without any NAT support?
Yes, without NAT support for the base spec or initial v4 support.
Then we should move on and figure out how existent NAT traversal
techniques are suitable for SHIM6 and see if additional stuff is needed
The option proposed for this in the draft is:
When CGA is used to prevent redirection attacks in shim6, there is
constraint on the locators that are used apart from host B must
its own locators so it can pass it them to host A. In particular,
can use IPv4 addresses as locators; this doesn't require anything
more than defining how an IPv4 address is carried in the 128-bit
fields in the Locator List option.
I wonder if it wouldn't be better to change the verification method
field to a generic Flag field and use some bits there to specify the
address family, what do you think?
We can encode the address type in different ways. One way would be to
use a flag field in the verification method. Another would be to use
the IPv4-mapped address format (::ffff:22.214.171.124). Both would work
but i guess that my point is that if already identify that we may need
additional flags about the address information, it would be a good
option to redefine the verification method to a generic flag octet, in
order to support future flexibility (this is somehow independent of the
option selected for the v4 address, is more a general observation)
w.r.t. NAT i guess that an additional consideration is how does the
host detects its own addresses in order to include them in its own
locator set and communicate them to the peer. Of course, shim should
be able to detect private addresses and not include them in the
This is non-trivial. It also would need to know which peers are on the
near and far side of the NAT, since it needs to use different locators
in the two cases.
IMHO a reasonable trade-off would be now to specify how IPv4
addresses could be used as locators when no nat is involved and leave
the nat support for further study
I'm concerned about the slippery slope.
Ok, let's explore this a bit more...
wouldn't the Sent locator option and the received locator option be
useful for dealing with NATs?
I mean using these, a host can find out if the addresses were rewritten
(whether by a router or a nat doesn't matter i guess), and discover its
own addresses and eventually add them to the Ls
In addition, as you mention in the draft the failure detection
mechanism could be used to preserve the NAT state if detected
Probably the piece that is missing is somehow of rendez vous server for
initial contact for hosts behind nat
In the draft it is assumed that a single identifier will be available
for an endpoint. I don't see the need to have more than one, but i
guess it would make sense to consider the case, but we can probably
deffer this till later. However, it seems reasonable to have more
than one locator. The question would be at this point why not use
RFC3484 (or RFC3484bis) to select among the multiple locator pair
I guess there are two aspects of locator selection and the draft
focuses on the TE aspects (selecting between different global locators
with different prefixes based on the TE wishes of the destination);
selecting locators with different scope, home vs. CoA, private vs.
public is the other part.
I suspect that one would want some coupling between the ULID selection
and the locator selection. For instance, a host that wishes the
privacy benefits of temporary locators presumably also would use a
I guess that locator selection incorporates several elements:
- Preferences with respect the different types of locators (CoA vs.
HoA, scope, private etc)
- TE/policing issues (including local preferences and remote
preferences (the preferences of the peer))
RFC3484 can be used to express the tree items somehow (with its
limitations) (note that it does not help to determine if an address is
reachable or not, but it does take this information into account when
performing dest address selection)
In addition, the locator selection is performed:
- when the communication is initiated (whether when a routable id is
selected (just RFC3484) or when a non routable id is used and the shim
selects a correspondent locator)
- when a failure occurs,
- because of TE considerations, a host may choose to change the locator
I would say that in any of those cases, it is importnat to take into
account all the aforementioned 3 items, so i guess that RFC3484 may be
a good candidate for locator selection
Moreover, i would wonder if it didn't make sense to use RFC3484 to
select locators after a failure i.e. to select the locators to
explore after a failure is detected using RFC3484 for that, or even
if we have multiple address pairs that are working as locators, to
use RFC3484 to select which one among them to use to rehome the
What part of RFC 3484 do you see as useful for this?
As an example, one way to explore other locators after a failure is to
try one that is maximally different from the failed locator (i.e.
differs in the leftmost bit) since such a locator might be a more
independent path. The point with this example is that RFC 3484 takes
no such consideration into account.
But not only availability must be taken into account for exploring and
rehoming i guess.
First of all, you probably want to take into account considerations
like scope, HoA vs. CoA, private vs. public addresses when selecting
which address to explore
Second, you also may want to take some policy/TE considerations into
(e.g. suppose you have a site with 3 links, 2 of them with a flat rate
and the third one with per traffic rate. Probably you will want to use
always that flat rate first and only fall back to the per traffic rate
if those two ae down, independently of the number of bits that the
source address has in common)
I guess that the information in SRV records is about the peer's
preferences about its own locators
The same thing w.r.t. the preference information received in the
preference option of the shim protocol
however, the local host may also have some policy w.r.t. which
locator prefer when there are multiple of them for a given
I guess that the local preferences will be expressed in the RFC3484
I was actually envisioning that the source locator selection would be
driven by the same type of information (priority and weight) as the
remote end sends us (in the Locator Preference option) for the
Thus one way to do this is independent selection of source locator
(based on the locally configured priority and weights) and destination
locator (based on the Locator Preference option).
I don't see what the RFC 3484 table would add; we do need to consider
address scope etc which is something to carry forward from RFC 3484.
Not sure i understand the last sentence.
but i guess we need to consider scope/HoA/private etc when selecting
And i guess that a multihomed host may also have preferences about
which destiantion address to use for reaching a destiantion and may
want to override the preferences of the peer, especially when he is
sending traffic. I mean, each end has the possibility of selecting the
locator pair that it want to use for sending. It may take into account
the peer's preferences, but it will have the final choice in any case.
does this makes sense?
So for both of these issues, RFC3484 could be useful
In any case, i guess your model is much direct and maybe we could adopt
it and not precluding more complex setups in the future
I have two comments w.r.t. to the mechanisms presented:
First, i think that the idea to carry the Sent Locator Pair and
Received Locator pair options to discover and allow coordination
between routers and hosts is very clever. As i understand it the main
focus is putted in the case where host A learns through this option
new locators of its own.
However, it may be case that a host receives a payload packet with a
new locator from its peer i.e. the source locator is not included in
Ls(peer). In this case, it will accept the packet since the CT match,
but it cannot use it to send packets until a CGA/HBA verification of
this locator is presented by the peer. However, when it sends the new
locator in the received locator option, the peer should sent an
Update request the includes the new locator signed with CGA. I am not
sure if this is what is expressed in the last bullet of section
That bullet just says to inform the peer that its locators were
rewritten in a new way.
But the draft mentions somewhere that the host can "adopt" a locator
that the routers using, and if it does this, it would presumably send
an Update Message to the peer saying that it is ok to send to this new
locator (and provide the CGA signature to prove it).
Second, i think that the presented mechanisms are potentially very
useful for rewriting payload packets, but i really don't think it
worth the effort to rewrite the source address of the shim control
message. I mean, they are a fairly reduced amount of packets, so i
guess that they don't really affect TE considerations. Supporting
this adds additional complexity to a protocol which is already fairly
complex imho. I mean, i guess it can be done as you present in the
draft, but i don't think we win much with allowing rewriting of these
few packet and we would be adding much complexity. I would keep it
just for data packets and not for signalling packets
One of the interesting things is the combination of the unroutable
ULID and getting router feedback during the context establishment
exchange (which will be done before any ULP packets are exchanged in
If we only allow rewriting on packets with the payload extension
header we wouldn't have that capability of early locator selection
according to the policy implicit in the router's rewriting.
but how early is this compared to the case where no rewriting is
supported for control packets?
I mean, in the case of no rewriting for control packets, the first
payload packet would get rewritten and the capability would only get
delayed for 2 packets i.e. the shim context establishment packets,
which i don't think is an issue...
but probably i am missing the point you are making...