SHIM6 WG E. Nordmark
Internet-Draft Sun Microsystems
Expires: August 26, 2008 February 23, 2008
Extended Shim6 Design for ID/loc split and Traffic Engineering
draft-nordmark-shim6-esd-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 26, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Nordmark Expires August 26, 2008 [Page 1]
Internet-Draft Extended Shim6 Design February 2008
Abstract
The Shim6 protocol provides for locator agility while satisfying the
'first, do no harm' security requirements. This document outlines
three rather orthogonal sets of extensions to Shim6. The first one
is how to procide complete separation between identifiers and
locators. The second one is how to allow routers to rewrite the
locators in the shim6 packets as a way to provide traffic engineering
information to the hosts. The third one is the outline of a simple
extension to allow shim6, with a CGA upper-layer ID, to operate using
IPv4 addresses as locators.
The purpose of this outline is to stimulate discussions.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Identifier/Locator split . . . . . . . . . . . . . . . . . 3
1.2. Traffic Engineering . . . . . . . . . . . . . . . . . . . 4
1.3. Shim6 using IPv4 addresses as locators . . . . . . . . . . 5
2. Identifier/Locator Split . . . . . . . . . . . . . . . . . . . 6
2.1. Syntax, Semantics, and Allocation of non-routable
identifiers . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Domain name lookup to find the Identifier . . . . . . . . 7
2.3. Identifier Lookup to find the Locators using the DNS . . . 7
2.4. Handling Application Referrals . . . . . . . . . . . . . . 7
2.5. Walkthrough of an example . . . . . . . . . . . . . . . . 8
2.6. Design Alternatives . . . . . . . . . . . . . . . . . . . 9
3. Traffic Engineering Support . . . . . . . . . . . . . . . . . 11
3.1. Recommending use of DNS SRV . . . . . . . . . . . . . . . 11
3.2. DHCPv6 option for Locator Preferences . . . . . . . . . . 12
3.3. Identifier to Locator lookup Preferences . . . . . . . . . 12
3.4. Locator Rewriting by Routers . . . . . . . . . . . . . . . 12
3.5. Walkthrough using locator rewriting . . . . . . . . . . . 13
3.6. Need for Coordination? . . . . . . . . . . . . . . . . . . 15
4. New Option Formats . . . . . . . . . . . . . . . . . . . . . . 17
4.1. New DHCPv6 Option . . . . . . . . . . . . . . . . . . . . 17
4.2. New Shim6 Options . . . . . . . . . . . . . . . . . . . . 18
4.2.1. Sent Locator Pair Option Format . . . . . . . . . . . 18
4.2.2. Received Locator Pair Option Format . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Normative References . . . . . . . . . . . . . . . . . . . 23
7.2. Informative References . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27
Nordmark Expires August 26, 2008 [Page 2]
Internet-Draft Extended Shim6 Design February 2008
1. Introduction
This document describes extensions to Shim6 [7] to handle complete
separation between identifiers and locators and also to provide
better feedback to the host for the purposes of traffic engineering.
The Shim6 protocol provides for locator agility while satisfying the
'first, do no harm' security requirements [22]. We believe that the
only existing two approaches which satisfy these requirements are
shim6 and HIP [30]. Satisfying those requirements seem to imply some
additional state on the endnodes, at least when the locator agility
mechanism is implemented in layer 3 as opposed to being folded into
every transport protocol; if it was folded into the transport
protocols one could probably include this information in the
transport protocol state and exchanges. As such, these approaches
require some additional state management which results in packet
exchanges.
This document outlines some extensions to Shim6 that in addition
provides complete separation between identifiers and locators, and
allows routers to rewrite the locators in the shim6 packets as a way
to provide traffic engineering information to the hosts.
1.1. Identifier/Locator split
Shim6 as currently specified states that the upper-layer identifier
(ULID) is one of the IPv6 locators of the host. However, the
protocol exchanges in shim6 do not require this, and there is already
a ULID-pair option that can be conveyed in the shim6 establishment
exchange. Thus in the protocol exchanges we can just carry that
ULID-pair option in all the shim6 control messages (I1, R1, I2, R2,
R1bis, I2bis, Update Request, Update Acknowledgement, Keepalive, and
Probe). But that in itself doesn't solve the problem; a large piece
of the problem lies in:
o What is the syntax and semantics of an identifier.
o How are identifiers allocated to hosts.
o How do the hosts find a Identifier from a domain name.
o How do application referrals [27] work.
XXX Add TBD for referals using non-routable ULID - need to know peer
application is running on a system capable of looking them up.
This document makes some, not completely arbitrary, assumptions for
the above issues, and presents an outline of how things could work
Nordmark Expires August 26, 2008 [Page 3]
Internet-Draft Extended Shim6 Design February 2008
given those assumptions. The document shows that there is some
additional setup cost associated with identifier/locator separation
compared to shim6 just switching between a set of locators. We argue
that some additional overhead is inevitable; the benefits of
identifier/locator separation is to provide a layer of indirection
between the two, and this indirection necessitates some form of
lookup as part of initiating communication to an identifier.
1.2. Traffic Engineering
With the current style of IPv4 multihoming, which uses a single IP
address prefix and BGP, there is a range of BGP techniques that can
be used to affect the routing for that single prefix, and as a result
effect which path incoming traffic use to reach the site. Also, the
site itself can use some internal routing control to select which
egress path to use should a route be available via multiple egresses.
In any scheme that uses multiple address/locator prefixes per site
the mechanisms to control which packets flow over which ingress and
egress are likely to be completely different, since BGP would not be
able to correlate the different prefixes that are assigned to a
single site. This might imply that the traffic engineering
capabilities might be quite different.
As specified in shim6, the hosts select the ULID-pair, which by
convention is the initial locator pair, using RFC 3484bis [16]. With
the extensions specified in these documents there are two cases to
consider, depending on whether the ULID is a locator or the ULID is a
non-routable identifier:
o For ULIDs that are locators, RFC 3484bis still applies. In
addition, DNS SRV records [10] can be used as a way to give the
destination site some influence over which ULID = initial locator
is used, but that requires that the applications use SRV records.
o With ULIDs that are non-routable identifiers, there will most
likely be only one identifier for the destination as well as the
source. Thus the role of RFC 3484 is largely removed. But there
is an additional step of looking up the identifier to find the
locator, and at that point in time it makes sense to consider
traffic engineering for selecting the initial locator pair.
In both cases, shim6 already provides the mechanism of a Locator
Preference option which can be used by the peers to change the
preferences. But this mechanism assumes that there is a mechanism by
which a host in a site could be informed of its site's preferences.
We outline a DHCPv6 option in this document that could be used to
convey this information.
Nordmark Expires August 26, 2008 [Page 4]
Internet-Draft Extended Shim6 Design February 2008
1.3. Shim6 using IPv4 addresses as locators
When CGA is used to prevent redirection attacks in shim6, there is no
constraint on the locators that are used apart from host B must know
its own locators so it can pass it them to host A. In particular, we
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.
As is the norm when suggesting to run an protocol over IPv4, after 5
milliseconds the question is raised how the protocol can operate over
IPv4 NAT boxes. For all protocols that adds one or two orders of
magnitude or more complexity, and shim6 is no exception. The
complexities lie in:
o Handling initial contact from the public side of the NAT box to a
host on the private side of the NAT box. All protocols end up
with some form of 3rd party device on the public side in order to
handle this.
o Maintaining the NAT state in the NAT box, and detecting when this
state has been lost and must be recreated. For shim6 the failure
detection mechanism [9] can detect this.
o Being able to recreate that state in the NAT after it has been
lost.
Thus while supporting IPv4 addresses as locators is easy, running
across NATs is complex. It is far from clear that this is worth-
while pursuing.
Nordmark Expires August 26, 2008 [Page 5]
Internet-Draft Extended Shim6 Design February 2008
2. Identifier/Locator Split
This section outlines how non-routable identifiers can work in the
whole system, including their lookup and how they are used in shim6.
There are likely to be alternative designs, so this is by no means
believed to be the optimal approach, but working out some number of
details is still a useful exercise and helps have more concrete
discussions.
2.1. Syntax, Semantics, and Allocation of non-routable identifiers
In order for applications, which have been ported to use the IPv6
APIs that carry 128-bit IPv6 addresses, to not have to be ported
again, it makes sense to try to make do with an syntax that fits in
128 bits. Note that one could wish that we could apply this to the
IPv4 32-bit APIs, but with a future Internet with more than 4 billion
hosts, trying to support the IPv4 APIs to identify each host would be
impossible.
Since we are likely to have applications communicate to both hosts
which have an IP identifier and those which only have the IP
locators, it is highly desirable to be able to have a syntactic means
to tell an IP identifier apart from an IP locator. A reasonable
approach is to allocate a small subset of the IPv6 address space [23]
to be non-routable IP identifiers, in a similar means to the KHI
approach [24].
The desired semantics of an IP identifier is to be a name that refers
to an instance of the IP protocol. Hence it should not be bound to a
particular network interface. Also, it is desirable for the
identifier to be long term stable, for instance ensuring that the
identifier survives renumbering.
As we will discuss below, for application referrals to work using
128-bit IP "addresses" as handles for another host, there has to be
an efficient and scalable way to look up an identifier and find the
locators. An obvious way to get scalability is to do hierarchical
allocation of the identifiers, since this allows for a scalable,
hierarchical organization of a lookup system and also ensures that
the identifiers are unique.
While it certainly isn't the only possibility, in order to work out a
complete picture, this document suggests such a hierarchical
allocation, in such a way that at least 64 bits of the identifier is
left to each site to allocate. (With 64 bits we can use CGA to
"prove" identifier ownership as a way to prevent redirection attacks
from off-path attackers.)
Nordmark Expires August 26, 2008 [Page 6]
Internet-Draft Extended Shim6 Design February 2008
2.2. Domain name lookup to find the Identifier
Many applications start their communication by knowing the fully-
qualified domain name of the peer, and they look this up in the DNS
to find AAAA and A records for that peer. As we introduce a separate
IP Identifier we want the same capability, but we also need to avoid
disturbing existing IPv6 hosts which would not be able to deal with
an IP identifier, since they assume all AAAA records contain routable
locators.
A conceptually clean way to handle this is to introduce a separate ID
resource record type in the DNS, which has the same right-hand side
as the AAAA records. Then hosts which implement support for the IP
identifier would first look for an ID record, and if none found, look
for AAAA and A records. This would work, but adds inefficiencies
until (or unless) most hosts have ID records.
An alternative would be to overload AAAA records to contain both
identifiers and locators and rely on RFC 3484 to avoid accidentally
picking an identifier on a host which doesn't understand what an IP
identifier is. Then the hosts which do understand IP identifiers can
ignore the routable locators in the AAAA RRset. The choice between
those two, or other alternatives, doesn't materially affect how the
rest of identifier/locator separation would work.
2.3. Identifier Lookup to find the Locators using the DNS
One can do different forms of lookup systems for the identifier to
locator lookup. The least "novel" one would be to reuse the DNS.
Since the identifier is drawn from the IPv6 address space, a possible
way to do this in the DNS is to use the ip6.arpa tree for this, with
its ability to delegate on nibble boundaries.
A simple way to do this would be to just have normal PTR records in
the reverse tree that "point" to a fully-qualified domain name, and
then do lookups for AAAA records matching that domain name. But this
doesn't allow the destination domain to influence the locator
selection as part of the lookup. Thus it might make sense to instead
deploy DNS SRV records in the reverse zone since this would allow
specifying a priority and a weight for primary/backup and load
spreading, respectively.
2.4. Handling Application Referrals
A referral is the case when three or more instances of an application
interacts and the first instance communicates with the second
instance, and then communicates with the third instances and wishes
to tell the third instance how to contact the second instance. There
Nordmark Expires August 26, 2008 [Page 7]
Internet-Draft Extended Shim6 Design February 2008
are application patters, called callbacks and long-lived application
associations in [27] that have similar issues. The application can
handle these by using and passing the fully-qualified domain name, or
it can do it by storing and passing the IP address. In the latter
case, this application ends up depending on the IP address being
universally useful as a way to contact another host.
Assuming we want to keep such applications functioning with the
introduction of the identifier/locator split, it is necessary that
the 128 bit identifier can be useful on a host which didn't do the
DNS lookup and does not know the fully-qualified domain name of that
peer.
The approach outlined in this section handles this case, since the
identifier will be looked up in ip6.arpa to find the locators.
2.5. Walkthrough of an example
The following example shows how the above use of DNS interacts with
shim6. This assumes that the destination host, www.example.com, has
been allocated an IP identifier and that IP identifier has been
entered as an ID RR in the DNS.
1. The application calls getaddrinfo() for www.example.com, and that
performs a DNS lookup for an ID record for www.example.com.
Since a record was found, it returns this as a 128-bit IPv6
address. (If no records was found, then getaddrinfo() would have
looked for AAAA and A records.)
2. The application, without making any distinction between an IP
identifier and a locator, passes this address to the connect() or
sendto() calls, depending on which transport protocol it uses.
3. The transport protocol proceeds as normal, which includes picking
a source address which "matches" the destination address. The
RFC 3484 rules might very well be sufficient for this;
alternatively the transport protocols would be modified to
explicitly know that when the destination is an identifier (it
has a well-known, KHI-like prefix) it must pick a source address
which is also an identifier, and vice versa for a destination
which is a locator.
4. A packet (for instance, a TCP SYN) from the transport protocol
arrives at the shim6 shim layer on the host. The shim looks for
a context which matches the ULID pair. Since we assume this is
the first attempt to communicate with this ULID, there is no
existing context.
Nordmark Expires August 26, 2008 [Page 8]
Internet-Draft Extended Shim6 Design February 2008
5. The shim checks if the destination ULID is a locator or an
identifier. If it is a locator it proceeds as specified in Shim6
[7] and none of the items below apply. If it is an identifier,
then the shim needs to find the set of locators for the
identifier.
6. The shim performs the identifier to locator lookup very similarly
to normal IPv6 reverse lookups (form a query name based on the
nibbles in reverse order and append ip6.arpa), but it queries for
SRV records.
7. Assuming one or more SRV records are returned, the shim takes the
priority and and weight into account as specified in [10] to
order the locators.
8. The shim then forms a I1 packet as specified in [7] and includes
a ULID pair option (to carry the ULIDs which are different than
the locators).
9. The rest of the context establishment follows as in [7] with the
ULID option. The presence of the ULID option implies that the
peer will verify the locators using the CGA ULID properties when
receiving the I2 message, and the host itself will verify its
peer's locators the same way when receiving the R2 message.
The rest of shim6 remain unmodified, except that the Locator Update,
Keepalive, and Probe messages should probably carry the ULID option
as well. Alternatively, one could rely on the 47-bit context tag to
identify the context.
Note that the above assumes that the site controls the DNS reverse
tree for their identifier prefix. But there is no dependency on the
reverse tree for the locator prefixes that the site is using.
In order to provide an IP identifier that is not a routable IP
address, we would presumably need to provide host autoconfiguration
capabilities for the identifier. This could be done as some minor
extensions to DHCPv6 and Stateless Address Autoconfiguration, as long
as the identifiers would be automatically registered in the DNS as
part of such assignment.
2.6. Design Alternatives
If the identifiers are placed in the DNS using AAAA records, then the
lookup for the AAAA record set (to find the identifier) might also
return a list of locators. Such a list can potentially be useful to
avoid the ip6.arpa lookup to find the locators. But relying on this
means that the reverse lookup from the identifier will only be used
Nordmark Expires August 26, 2008 [Page 9]
Internet-Draft Extended Shim6 Design February 2008
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 [27] that are IP addresses.
For this reason it makes sense to be more consistent and always rely
on the reverse lookup when the context is established.
Nordmark Expires August 26, 2008 [Page 10]
Internet-Draft Extended Shim6 Design February 2008
3. Traffic Engineering Support
The traffic engineering pieces that might be desirable and that are
easy to implement in this model are outlined in this section. If the
ULID is a routable locator, then it makes sense to recommend that
applications use DNS SRV records for the initial (non-shimmed)
contact, and also provide at least a DHCPv6 option by which a site
administrator can control what each host in the site uses in the
shim6 Locator Preference option.
In the case when the ULID is a non-routable identifier, a different
set of mechanisms are desirable. Instead of using DNS SRV records
for the lookup of the domain name of the peer, we want similar
control when looking up an identifier to find the set of locators.
For both cases it has been argued that allowing the routers, in
particular routers located close to the egress from a site, to
rewrite the source locators, as a mechanism to indicate to the hosts
a dynamic change in the preferred locators. We outline the mechanism
for this below and we also discuss the policy issues which are
introduced with this additional information from the routers.
Note that we do not currently have a set of agreed upon requirements
for traffic engineering. The closest we have to requirements are
Jason Schiller's slides at
http://www.iab.org/documents/open-mtgs/2005-10-23-schiller.pdf
3.1. Recommending use of DNS SRV
In shim6 as specified, the host rely on existing DNS mechanisms, such
as AAAA records or any other mechanism, to find a list of locators to
try. When AAAA records are used, there is no mechanism for the
destination site to express any ranking for primary/fallback, or any
mechanism to spread load across the paths that are represented by the
locators, since the AAAA resource record set is treated as a set with
no implied order.
If we could use DNS SRV records instead, then we would have the
combination of the SRV priority (for primary/backup) and SRV weight
(for specifying a weighted, random load spreading) as tools for the
site administrator to use.
Unfortunately it is the application software developer which needs to
explicitly decide to use SRV records, thus we can not require that
shim6 implementations also have the applications use SRV, since the
application developer is in most cases different than the implementor
of the TCP/IP protocol stack. But it would be helpful to the IETF to
make a strong recommendation that applications should use SRV
Nordmark Expires August 26, 2008 [Page 11]
Internet-Draft Extended Shim6 Design February 2008
records.
Note that in some cases it quite complex to specify how an
application uses SRV records. SIP is an example of this [13], which
needs to deal with SIP running over multiple transport protocols, SRV
vs. AAAA and A record ordering, and various other issues. But in
common cases like http that run over a single transport, the needed
change is just to precede the lookups for AAAA and A records at
www.example.com with a lookup for SRV at _http._tcp.www.example.com.
3.2. DHCPv6 option for Locator Preferences
Shim6 [7] specifies a Locator Preference option which can carry some
number of octets, with the protocol currently specifying the
semantics of the first three octets of each preference element. One
way to allow the site administrator to control this is to introduce a
new DHCPv6 [14] option which carries the list of IPv6 locator
prefixes that the site uses and the octets of shim6 preference
element; this can be done without the host having to understand the
semantics of the octets it is sending - it can just copy them from
the DHCPv6 option, even though the host will interpret the locator
preference octet string it receives from the peer.
To be concrete, we show an example of what such a DHCPv6 option can
look like in Section 4.1.
3.3. Identifier to Locator lookup Preferences
As specified in Section 2.3 it makes sense to use SRV records for the
reverse lookup used to go from an identifier to a set of locators,
since this allows the site manager to provide priority and weight to
the peer before the initial contact takes place, thus most likely the
initial locator chosen by the host will be a reasonable one from the
perspective of traffic engineering for the peer site.
3.4. Locator Rewriting by Routers
Shim6 as specified [7] allows routers to rewrite the locators on
shim6 packets that are payload extension headers, but it does not
allow such rewrites on the shim6 control messages. In this section
we outline what it would take to allow such rewriting on all the
shim6 messages, and also provide the host with an indication of how
their locators are rewritten so that they can take this into account.
With these extensions the routers are free to rewrite the locators
with alternate values in any IPv6 packet that has a shim6 header
(i.e., where some next header value is IPPROTO_SHIM6).
Nordmark Expires August 26, 2008 [Page 12]
Internet-Draft Extended Shim6 Design February 2008
The support for this rewriting consists of:
o Introducing a new Sent Locator Pair option, which the receiver or
a packet can use to see how the routers rewrote the locators in a
packet sent towards it. The receiver also "echos" this
information to its peer using the next option.
o Introducing a new Received Locator Pair option, which is a echo of
the content of a received Sent Locator Pair option.
o The hosts SHOULD include a shim6 extension header for ULP payloads
where the sending shim does not rewrite the locators, in order to
allow the routers to rewrite the locators.
o To maximize the utility of the locator rewriting, we should avoid
the use of deferred context establishment. If the first packet
sent is an I1 packet, and the above SHOULD is honored, then the
routers are free to rewrite the locators in all the packets that
are exchanged between a pair of shim6 hosts. (If we are also
doing complete identifier/locator split, then there is no deferred
context establishment, thus this doesn't add any additional
costs.)
o As in the current shim6 specification, any source and destination
locator can be used on a shim6 payload message as long as the
context tag matches. But in addition, when the receiver of a
payload message observes a change in the locator pair on which it
receives the payload extension headers, it SHOULD notify the peer
of this by sending an Update Request message with a Received
Locator Pair option. Such update messages MUST be rate limited
since the locators can flap when routing is flapping.
3.5. Walkthrough using locator rewriting
The following example shows how the Sent Locator Pair and Received
Locator Pair options are used as part of the Shim6 context
establishment exchange, and indicates some of the policy choices that
exist in terms of what locator is chosen. The same exchange applies
whether the ULID is a reachable locator or not; when the ULID is an
unreachable identifier then there would be an ULID option in most of
the shim6 control messages, but we omit that aspect here as we focus
on the locator exchanges.
We assume that host A, which locators A1, A2, and A3, is
communicating with host B, with locators B1 and B2.
The walkthrough starts when A is sending an I1 message to B:
Nordmark Expires August 26, 2008 [Page 13]
Internet-Draft Extended Shim6 Design February 2008
1. The shim then forms a I1 packet as specified in [7] and includes
a Sent Locator Pair option. The shim has chosen A1 to be the
source locator and B1 to be the destination locator, thus it
places <A1, B1> in both IPv6 header (as source and destination),
and in the Sent Locator Pair option.
2. The routers, for instance, the egress router from A's site, might
rewrite the IPv6 source address field with a different prefix so
that when the packet is receive by B it has <A2, B1> in the IPv6
header (and the Sent Locator Pair option is unmodified with <A1,
B1>).
3. B processes the I1 message as specified in [7] to generate a R1
message. In addition, it copies the content of the Sent Locator
Pair option into a Received Locator Pair option. Host B must
decide whether it should send the R1 message to the IP source
address of the R1 message, or send it to the potentially
different Sender Locator in the Sent Locator Pair option in the
I1 message. The safe thing would be to send it to the source
address of the R1, because the alternative can be used for
reflection attacks. Once B has made this decision, it puts the
addresses, in this example <B1, A2> in the IPv6 header as well as
into a Sent Locator Pair option.
4. Host A receives the R1 message and finds the context state. At
this point in time A can see how the router rewrote the I1
message by comparing the Lp(local), Lp(peer) with the Received
Locator Pair option. It can also see how the locators were
rewritten for the return path by comparing the IPv6 header in the
R1 message with the Sent Locator Pair option. It might be that
the Received Locator Pair option has a Sender Locator which is
not one of the locators that host A knows as its own. In this
case it it might reasonable for A to treat this locator as its
own, at least in terms of accepting packets destined to it. Host
A forms a normal I2 message, but also includes a Received Locator
Pair option in it. The host chooses the locator pair to use when
sending the I2 message, and if the source address of the R1
message is one of B's locators, then this might be the best
choice. Just as for the I1 message, the host adds a Sent Locator
Pair option to the I2 message which contains a copy of the source
and destination fields in the IPv6 header.
5. Host B receives the I2 message and finds the context state. At
this point in time B can see how the routers on the return path
rewrote the I2 message by comparing the IPv6 header in the I2
message with the Sent Locator Pair option. It might be that the
Received Locator Pair option has a Sender Locator which is not
one of the locators that host B knows as its own. In this case
Nordmark Expires August 26, 2008 [Page 14]
Internet-Draft Extended Shim6 Design February 2008
it it might reasonable for B to treat this locator as its own, at
least in terms of accepting packets destined to it. Host B forms
a normal R2 message, but also includes a Received Locator Pair
option in it. The host chooses the locator pair to use when
sending the R2 message, and if the source address of the I2
message is one of A's locators (that it in the Locator List
option), then this might be the best choice. Just as for the R1
message, the host adds a Sent Locator Pair option to the R2
message which contains a copy of the source and destination
fields in the IPv6 header.
The host maintains Lp(local) and Lp(peer) to use as the preferred
source and destination address when sending packets to the peer. But
in addition the hosts main a Lr(local) ["r" for "received"] and
Lr(peer) that is the locator pair in the most recently received
packet for the context.
When a packet with a Payload Extension Header is received for the
context and the source or destination address does not match
Lr(peer)/Lr(local), then, subject to rate limiting, the host forms an
Update Request message with a Received Locator Pair option. This
Update Request message is transmitted and retransmitted as specified
in [7]. This allows the peer to be notified should the routers
change the way the rewrite the locators, which the host can use to
make sure the packets have the correct locators as they are
originated.
3.6. Need for Coordination?
It might be the case that the routers are not aware of the the actual
prefixes assigned to each host. For instance, just because a site
has 7 different prefixes, there might be some host that due to
resource considerations or DHCP sever policy only configure addresses
in a subset of these prefixes. Thus the routers might rewrite the
source locator to be a locator which is not assigned to the source
host. If host B were to respond to an I1 message that had been
rewritten this way, then the R1 message would not be accepted by host
A. For this reason it is recommended that the I1 and R1 messages
include the Locator List option, and that the receiver of these
messages reply using the Sender Locator in the the Sent Locator Pair
option, in the case when the IPv6 source address is not part of the
Locator List option.
Also, it is recommended that hosts "learn" new locators from the
Received Locator Pair option, so that they will in the future accept
packets destined to the locators that they routers use when
rewriting, even if the hosts aren't otherwise configured with those
addresses. Note that for shim6 to be able to prove to the peer that
Nordmark Expires August 26, 2008 [Page 15]
Internet-Draft Extended Shim6 Design February 2008
the host in fact "owns" such a locator, the host must have a CGA ULID
and sign an Update Request message with the new locator set. Whether
it is a good idea to always "adopt" locators from the Received
Locator Pair option is TBD.
Nordmark Expires August 26, 2008 [Page 16]
Internet-Draft Extended Shim6 Design February 2008
4. New Option Formats
4.1. New DHCPv6 Option
This option follows the DHCPv6 [14] format for options and allows the
DHCP server to specify what the host will put in the Shim6 Locator
Preference option. The DHCPv6 option carries IPv6 address prefixes,
and the host will apply the logest matching such prefix to each of
its IPv6 locators.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length1| |
+-+-+-+-+-+-+-+-+ Prefix 1 |
| |
| +-+-+-+-+-+-+-+-+
| | Elem len 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element 1 (len octets) | Prefix Length2| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Prefix 2 |
| |
| +-+-+-+-+-+-+-+-+
| | Elem len 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element 2 (len octets) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
option-code: 16-bit unsigned integer. To be allocated by the IANA.
option-len: 16-bit unsigned integer. The length in octets of all
the fields in the option which follow the option-len
field.
Prefix Length[n]: 8-bit unsigned integer. The number of relevant
bits in Prefix[n].
Prefix[n]: An IPv6 address prefix. The length of this field is
the number of octets necessary to carry Prefix
Length[2] bits. For instance, a 47-bit Prefix Length
would mean that the Prefix field is 6 octets.
Nordmark Expires August 26, 2008 [Page 17]
Internet-Draft Extended Shim6 Design February 2008
Element Len[n]: 8-bit unsigned integer. The number of octets of
Element[n] that follows the Element Len field.
Element[n]: One or more octets that can be directly copied to the
Shim6 Locator Prefix option's Element field.
4.2. New Shim6 Options
This document defines two new Shim6 options.
+------+-----------------------+
| Type | Option Name |
+------+-----------------------+
| 13 | Sent Locator Pair |
| | |
| 14 | Received Locator Pair |
+------+-----------------------+
Table 1
4.2.1. Sent Locator Pair Option Format
This option carries the set source and destination locators as sent
by the sender, that is, the sender sets them to the same values as
the IPv6 source and destination fields. When router rewriting is in
use, then the routers might change the IPv6 source and destination
fields, this field allows the receiver to observe how the locators
were rewritten, and also "echo" that back to the peer. This option
SHOULD be included in all the Shim6 control messages.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 13 |0| Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Sender Locator +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Receiver Locator +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Nordmark Expires August 26, 2008 [Page 18]
Internet-Draft Extended Shim6 Design February 2008
Reserved2: 32-bit field. Reserved for future use. Zero on
transmit. MUST be ignored on receipt. (Needed to
make the ULIDs start on a multiple of 8 octet
boundary.)
Sender Locator: A 128-bit IPv6 address.
Receiver Locator: A 128-bit IPv6 address.
4.2.2. Received Locator Pair Option Format
When a host receives a shim6 control message, such as an I1 or Update
Request message, from its peer and will send a response message, then
if the "request" contained a Sent Locator Pair option, the host will
"echo" that option in unchanged but with the option type changed to
be a Received Locator Pair option. This allows the sending host to
see how the router rewrote its locators, which is useful information
for its locator selection.
The control messages that carry a Received Locator Pair option should
also carry a Sent Locator Pair option, to allow the discovery of the
rewriting that happens in the reverse direction.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 14 |0| Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Sender Locator +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Receiver Locator +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Reserved2: 32-bit field. Reserved for future use. Zero on
transmit. MUST be ignored on receipt. (Needed to
make the ULIDs start on a multiple of 8 octet
boundary.)
Nordmark Expires August 26, 2008 [Page 19]
Internet-Draft Extended Shim6 Design February 2008
Sender Locator: A 128-bit IPv6 address.
Receiver Locator: A 128-bit IPv6 address.
Nordmark Expires August 26, 2008 [Page 20]
Internet-Draft Extended Shim6 Design February 2008
5. Security Considerations
This document isn't known to introduce any new security
considerations other than those listed for Shim6 [7]. Since Shim6
satisfies the concerns specified in [22] that is likely to be
sufficient.
The suggest looking of identifiers to find the set of locators in
this document uses DNS. If DNSsec is not applied to the part of the
ip6.arpa tree where the IP identifiers are placed, then an attacker
could spoof the set of locators. This would result in a form of DoS
attack and not a redirection attack, since a host would verify the
CGA property when it receives the R2 message, and only the host which
"owns" the CGA-based ULID would be able to correctly sign the R2
message.
Of course, the DNS lookups of www.example.com to find the identifier
is still subject to DNS spoofing attacks, including redirection
attacks to a different ULID.
Nordmark Expires August 26, 2008 [Page 21]
Internet-Draft Extended Shim6 Design February 2008
6. Acknowledgements
Over the years many people active in the multi6 and shim6 WGs have
contributed ideas a suggestions that are reflected in this
specification. The original ideas that has stimulated this work was
Mike O'Dell's GSE proposal.
Nordmark Expires August 26, 2008 [Page 22]
Internet-Draft Extended Shim6 Design February 2008
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[4] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[5] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.
[6] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[7] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim
Protocol for IPv6", draft-ietf-shim6-proto-10 (work in
progress), February 2008.
[8] Bagnulo, M., "Hash Based Addresses (HBA)",
draft-ietf-shim6-hba-05 (work in progress), December 2007.
[9] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair
Exploration Protocol for IPv6 Multihoming",
draft-ietf-shim6-failure-detection-11 (work in progress),
February 2008.
7.2. Informative References
[10] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[11] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[12] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
Nordmark Expires August 26, 2008 [Page 23]
Internet-Draft Extended Shim6 Design February 2008
[13] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[14] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[15] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[16] Bagnulo, M., "Updating RFC 3484 for multihoming support",
draft-bagnulo-ipv6-rfc3484-update-00 (work in progress),
December 2005.
[17] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[18] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582, August 2003.
[19] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6
Flow Label Specification", RFC 3697, March 2004.
[20] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[21] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[22] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming
Solutions", RFC 4218, October 2005.
[23] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[24] Nikander, P., "An IPv6 Prefix for Overlay Routable
Cryptographic Hash Identifiers (ORCHID)",
draft-laganier-ipv6-khi-07 (work in progress), February 2007.
[25] Huitema, C., "Ingress filtering compatibility for IPv6
multihomed sites", draft-huitema-shim6-ingress-filtering-00
(work in progress), September 2005.
[26] Bagnulo, M. and E. Nordmark, "SHIM - MIPv6 Interaction",
draft-bagnulo-shim6-mip-00 (work in progress), July 2005.
[27] Nordmark, E., "Shim6 Application Referral Issues",
Nordmark Expires August 26, 2008 [Page 24]
Internet-Draft Extended Shim6 Design February 2008
draft-ietf-shim6-app-refer-00 (work in progress), July 2005.
[28] Bagnulo, M. and J. Abley, "Applicability Statement for the
Level 3 Multihoming Shim Protocol (Shim6)",
draft-ietf-shim6-applicability-03 (work in progress),
July 2007.
[29] Huston, G., "Architectural Commentary on Site Multi-homing
using a Level 3 Shim", draft-ietf-shim6-arch-00 (work in
progress), July 2005.
[30] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", draft-ietf-hip-base-10 (work in
progress), October 2007.
[31] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",
draft-ietf-mobike-protocol-08 (work in progress),
February 2006.
Nordmark Expires August 26, 2008 [Page 25]
Internet-Draft Extended Shim6 Design February 2008
Author's Address
Erik Nordmark
Sun Microsystems
17 Network Circle
Menlo Park, CA 94025
USA
Phone: +1 650 786 2921
Email: erik.nordmark@sun.com
Nordmark Expires August 26, 2008 [Page 26]
Internet-Draft Extended Shim6 Design February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Nordmark Expires August 26, 2008 [Page 27]