Internet DRAFT - draft-hain-6to4-scaling
draft-hain-6to4-scaling
NGtrans T. Hain
Internet Draft Microsoft
Document: draft-hain-6to4-scaling-01.txt November 2000
Expires: May 2001
6to4-relay discovery and scaling
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Abstract
The transition mechanism described in the 6to4 draft [2] [6to4]
raises scaling concerns when the matrix of IPv4 connected 6to4-
router systems, communicating across to the native IPv6 only
connected systems, are on the order of tens to hundreds of millions.
This document will address those concerns, offer additional
mechanisms for resolving them, and identify use for the scenario of
link-local addressing postulated in section 3.1.
Hain Expires May 2001 1
6to4 router discovery and scaling November 2000
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Table of Contents..................................................2
Conventions used in this document................................2
Terms..............................................................2
Overview...........................................................3
Basic assumptions................................................3
Mechanism..........................................................4
Scenarios..........................................................6
Fig. 1...........................................................6
Sequence Scenario 1:.............................................7
Sequence Scenario 2:.............................................7
Syntax.............................................................8
RS/RA option syntax..............................................8
NS syntax........................................................9
NA syntax........................................................9
Redirect syntax...................................................10
Additional Requirements...........................................11
Security Considerations...........................................11
Protection from random Router Advertisements:...................12
Protection from random redirects:...............................12
References........................................................12
Acknowledgments...................................................13
Author's Addresses................................................13
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [3].
Terms
6to4-router: an IPv6 router supporting a 6to4 pseudo-interface. It
is normally the border router between an IPv6 site and a wide-area
IPv4 network. When not acting as a relay, it advertises
[2002:IPv4::/48] as an attached prefix on IPv6 enabled interfaces.
Relay router: a 6to4-router configured to support transit routing
between 6to4 addresses and native IPv6 addresses. Advertises the
[2002::/16] as an attached prefix on native IPv6 enabled interfaces.
(referred to as 6to4-relay in this document)
6to4-normal host: an IPv6 host, which happens to have at least one
6to4 address learned from a 6to4-router. In all other respects it is
a standard IPv6 host.
6to4-integrated host: an IPv6 host that generates at least one 6to4
address and supporting 6to4 pseudo-interface from an IPv4 address.
It interacts directly with relays and remote routers, but in all
other respects it is a standard IPv6 host.
Hain Expires May 2001 2
6to4 router discovery and scaling November 2000
Overview
This document discusses scaling concerns of the mechanism defined in
[6to4]. The intent of this approach is to use the 6to4 mechanism as
a simplifier for providing IPv6 services to any node with a public
IPv4 address. (While IPv4-compatible IPv6 addresses are another
option, that mechanism raises concerns related to the scaling impact
on the native-IPv6 domain routing tables.)
The technical aspects of creating the appropriate addresses are not
an issue, but there is an area of concern related to simple
discovery of the path from 6to4 nodes to native-IPv6 routing domain.
Several schemes have been proposed, and the approach described here
does not preclude any of them. Rather it provides an alternative
that automates the process on a massive scale. Most importantly it
does so without requiring the 6to4-routers to participate directly
in a global routing process. As each 6to4-router potentially
represents a unique administrative domain, the complexity of
establishing routing protocols at this scale is directly
contradictory to the goal of simplicity.
A 6to4-router when not manually configured for routes, or
participating in a routing protocol over the 6to4 interface, finds
its route to the native IPv6 domain identically to a 6to4-integrated
host, thus for the purposes of this mechanism it will follow host
rules. To minimize confusion between routers that are configured or
participating in a routing protocol, and to maintain the context
that host rules apply, the rest of this document will use the term
'6to4-integrated host' when referring to hosts and routers that are
automatically deriving the path to the native-IPv6 domain.
Basic assumptions
1. A 6to4 based IPv6 deployment will not rely on ANY support from
local IPv4 only ISP's.
2. Consumer systems will be completely automated 6to4-itegrated
hosts. To make this automation work, a well-known relay service
needs to exist and be capable of handling greater than 10M
clients.
3. Greater than 10M nodes participating in a global EGP routing
process would create additional scaling concerns.
4. From the perspective of the 6to4-integrated host, the entire IPv4
Internet appears to be a single-subnet NBMA link-layer.
5. RA's from 6to4-relay routers are solicited only.
6. Prefix options in the RA on the 6to4 subnet are invalid.
Hain Expires May 2001 3
6to4 router discovery and scaling November 2000
Mechanism
While it is reasonable to expect that each ISP providing native-IPv6
services will be motivated to provide a relay service for their
customers to communicate with 6to4 sites, it is also expected that
these ISPs will generally not want to be the 'default' route between
6to4 and native-IPv6 infrastructures. They will also not be excited
about managing a massive manually configured tunnel array (no matter
which end the manual effort is applied to).
Automatic determination of a router on a link is normally
accomplished via link scope multicast to the all-routers address
(FF02::2). Since the IPv4 fabric appears as a logical NBMA link to
6to4-integrated hosts, identifying a router (specifically a 6to4-
relay router) on that link requires a non-multicast techniques. One
such technique would be use of a MARS system as defined in RFC 2491
[4]. This approach is administratively complex for the needs of
router discovery, but may be appropriate in some environments.
Another technique that maps well with the need for simplicity is
changing the discovery logic to use the subnet-router anycast
address. From RFC 2373 [5]:
'Packets sent to the Subnet-Router anycast address will be
delivered to one router on the subnet. All routers are required
to support the Subnet-Router anycast addresses for the subnets
which they have interfaces.'
Using the anycast address is normally intended for off-link
purposes, and on-link use is complicated due to the lack of a
mapping to a link layer address. For the purposes of 6to4, there is
a defined mapping to the IPv4 anycast for 6to4-relay routers as
defined in [6] [6to4any]. This also resolves the unknown state
raised in section 3.1 of [6to4].
While RFC 2491 defines IPv6 over NBMA networks, it is not a goal
here to emulate multicast over the 6to4 Internet link. The goal here
is to enable non-multicast based discovery.
RFC 2526 [7] defines the subnet-router anycast as the subnet prefix
followed by 0's. In this case, 2002::/128 identifies the IPv6
subnet-router anycast for any router on the IPv4 Internet logical
link. This is not particularly useful, but further refinement to
find the subset of routers that are acting as the relay to the
native-IPv6 routing domain results in 2002:IPv4anycast::/128.
Section 4.1 of [6to4any] defines the Default route in the 6to4
routers (::/0) as pointing to the 6to4 IPv6 anycast address. This
SHOULD be the pre-configured state of the 6to4-integrated host, and
treated as an alternate once an explicit 6to4-relay router is
learned.
Following the rules in section 6.3.7 of [8] [ND] (except destination
address), to discover a 6to4-relay router a 6to4-integrated host
sends a Router Solicitation message to the IPv6anycast/IPv4anycast
using a source as the local 6to4 address. The nearest (IPv4 routing
wise) 6to4-relay router will return the Router Advertisement from
Hain Expires May 2001 4
6to4 router discovery and scaling November 2000
its individual address fe80::IPv4/IPv4 to the scope consistent
fe80::IPv4/IPv4 of the 6to4-integrated host. This is necessary to
comply with RFC 2461 section 6, which requires RA to be sourced from
link local addresses.
When a router has been discovered, normal unicast NUD processing is
preformed. When this router has been determined unreachable, the
process begins again to find a new relay. While that is taking place
a 6to4-integrated host MAY choose to map all off-link destinations
in its neighbor cache to the relay anycast, allowing any available
relay to forward traffic, but SHOULD override those when a new 6to4-
relay is learned to provide immunity to potential routing
instability. There is no need for any 6to4-relay to maintain
neighbor state with the 6to4-integrated hosts, as the required
information for path determination is in the destination address of
each packet header.
The router lifetime in the RA SHOULD be set to update interval for
the routing protocol in the native IPv6 domain, but MAY be set
shorter. In any case, it MUST NOT be set to a period greater than
the routing update interval.
Since the IPv4 network appears as a link layer, all existing link
layer rules apply including redirect. To reduce the volume of
misdirected traffic, the redirect SHOULD apply to an entire prefix
when known. Given the 6to4-relay routers MUST be participating in a
routing protocol ([6to4] 5.2.3) to send routing entries for
2002::/16 into the native IPv6 network, they may be learning about
other 6to4-relay routers and their attached prefix. In this case, a
6to4-relay MAY choose to send a redirect to the 6to4-integrated host
for that prefix to optimize traffic flow symmetry.
All rules in section 8 of [ND] apply to redirects described here,
EXCEPT the one at the end of 8.2 that prohibits routers from
updating routes based on redirects. This rule only applies when the
6to4-router is participating in a routing protocol, or there are
configured routes over that interface. Note that for spoof
protection part of a previously reserved field is now defined.
As an alternative, simple devices MAY choose to set the neighbor
cache entry for all native-IPv6 domain destinations to the
IPv4anycast. If this option is chosen, there is no black-hole
detection, and the packet sequence is subject to routing flaps.
Another scaling issue is the expectation that all sources of RA's
are trusted, or there is an SA for AH between each router and host.
While this is reasonable for physical link technologies in a common
administrative domain, a new mechanism is required to support
logical link technologies like 6to4 where a logical link spans
multiple administrative boundaries. A new option (6) is defined for
both the RS and RA to provide some protection from spoofs by passing
a random 16-bit value generated and verified by the 6to4-integrated
host.
Hain Expires May 2001 5
6to4 router discovery and scaling November 2000
Scenarios
1. A Consumer system (6to4-integrated host) dials into their
preferred ISP and only receives IPv4 service. Using the 6to4
mechanisms as defined, the system creates IPv6 addresses for its
interface. Later an application attempts to connect to a system that
is connected to a native IPv6 network (global non-2002::). If no
other entry exists, the consumer system forwards the first packet to
the 6to4-relay anycast, and also sends an RS to that address. It
uses the RA to update its default route, and any redirect it
receives for the destination prefix. Further communications to
systems sharing that prefix are directed to the learned 6to4-relay.
NS messages SHOULD be sent to all known 6to4-relays to maintain the
Prefix / IPv4 address / Lifetime mapping until the path is idle for
at least two lifetimes, or the 6to4-relay is determined to be
unreachable.
2. An IPv6 only system in the native-IPv6 domain initiates a
connection to a web server in a 6to4 site. The nearest 6to4-relay
extracts the IPv4 address from the destination IPv6 address, and
tunnels per the 6to4 specification. The 6to4-router will use this
inbound packet to establish a neighbor entry in the incomplete
state, and then use the response from the web server to complete the
mapping between the native-IPv6 prefix, and its 6to4-relay. The
6to4-router SHOULD send NS messages to the 6to4-relay to maintain
this Prefix / IPv4 address / Lifetime mapping information until the
path is idle for at least two lifetimes, or the 6to4-relay is
determined to be unreachable.
------------- ------------ ----------- -------------
| Native IPv6 | | 6to4-relay | | IPv4 only | | 6to4-router |
| system |-/-| IPv6 ISP |---| Internet |-/-| |
------------- ------------ ----------- -------------
| |
----------------- -----
| 6to4-integrated | | Web |
| host | | site|
----------------- -----
-----
Fig. 1
Hain Expires May 2001 6
6to4 router discovery and scaling November 2000
Sequence Scenario 1:
1) The 6to4 process in a 6to4-integrated host automatically
sends packets for any global non-2002:: destination (that
does not match a prefix in the routing cache) to the 6to4-
relay anycast along with an RS.
2) The nearest 6to4-relay returns an RA from its unique IPv4,
and forwards packets within the IPv6 network. (It SHOULD
already be advertising the return route to 2002::/16)
3) The 6to4-integrated host establishes NUD with the 6to4-relay.
4) The 6to4 process in the 6to4-integrated host builds a routing
table cache from the redirect messages. It first verifies the
redirect through the new 'Relay Ident' field (IPv4 Identifier
in original tunnel packet). Subsequent tunneling is based on
longest match on prefix.
5) The native-IPv6 system sends Ack's via the nearest relay
advertising 2002::/16.
6) The native-IPv6 domain 6to4-relay extracts the IPv4 from
destination in packet header and tunnels the packet across
the IPv4 logical link.
7) The 6to4 process sends subsequent packets to the learned
native-IPv6 domain 6to4-relay until it is determined
unreachable.
------
Sequence Scenario 2:
1. The Native-IPv6 system looks up the name 6to4-web-site.
2. In this case DNS will return a 2002:: record, which MAY be in
a traditional round-robin for the web site.
3. The native-IPv6 system sends its first packet via the nearest
relay advertising 2002::/16.
4. The 6to4-relay extracts the IPv4 from destination in packet
header and tunnels the packet across the IPv4 logical link
using the 6to4 rules.
5. The 6to4-router for the web site forwards the packet to the
destination web site, and creates an INCOMPLETE entry in its
neighbor cache for the 6to4-relay.
6. The Web site sends an ACK via its 6to4-router.
Hain Expires May 2001 7
6to4 router discovery and scaling November 2000
7. The 6to4 process in the 6to4-router completes the neighbor
entry by sending an NS to the 6to4-relay.
8. The 6to4-router builds a routing table cache from the
redirect messages. It first verifies the redirect through the
new 'Relay Ident' field (IPv4 Identifier in original tunnel
packet). Subsequent tunneling is based on longest match on
prefix.
*** This creates a perceived problem because a router is
responding to redirect. ***
Actually RFC 1812 [9][routerreq] 5.2.7.2 states 'MAY consider
redirect when not running a routing protocol', which is the
case at hand; at least across this logical link.
9. 6to4-router forwards packets to the appropriate 6to4-relay
based on the longest match.
10. The 6to4-relay forwards to Native-IPv6 system.
-------
Syntax
RS/RA option syntax
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 (6) | Length (1) | Relay Ident |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Relay Ident - 16 bit random number for spoof protection in RA and
redirect
Hain Expires May 2001 8
6to4 router discovery and scaling November 2000
NS syntax
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 (135) | Code (0) | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Target Address (2002::IPv4anycast) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (2) | Length (1) | MUST be 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-Layer Address (IPv4 of 6to4-router) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NA syntax
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 (136) | Code (1) | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|S|O| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Target Address (FE80::IPv4) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (2) | Length (1) | MUST be 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-Layer Address (IPv4 of 6to4-relay) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (3) | Length (4) | Prefix Length |L|A| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Prefix (from table for this target) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code is set to 1 to identify new message with prefix information
R-bit is set as the 6to4-relay is logically a router
S-bit is set in response to solicitation
O-bit is cleared to prevent thrashing
Hain Expires May 2001 9
6to4 router discovery and scaling November 2000
Redirect syntax
(Expands scope for redirect from host to prefix)
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 (137) | Code (0) | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Target Address (FE80::IPv4) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Destination Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (2) | Length (1) | MUST be 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-Layer Address (IPv4 of 6to4-relay) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (3) | Length (4) | Prefix Length |L|A| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Prefix (from table for this target) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (4) | Length | Relay Ident |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IP header + data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP header + data is the original packet truncated to ensure that the
size of the redirect message does not exceed 1280 octets.
Valid lifetime and Preferred lifetime are set to the time remaining
until next scheduled BGP update
'Relay Ident' is used for spoof protection, and is filled in from
the 16 bits sent in the RS, also used in the Identity field of the
IPv4 header of the 6to4 packet.
Hain Expires May 2001 10
6to4 router discovery and scaling November 2000
Additional Requirements
IPv4 anycast address range assigned for this purpose.
6to4 integrated hosts, routers, and relays MUST recognize and
respond to ICMP messages targeted for [FE80::IPv4] that are received
on the 6to4 interface.
6to4-integrated hosts SHOULD establish NUD (as defined in section
3.8 of [10][mech]) with 6to4-relays they are redirected to, and
avoid thrashing if multiple relays exist for a given prefix. The
6to4-relays MAY establish NUD with the routers if desired, though
this will create scaling concerns with the only marginal benefit
being the rapid removal of access to nodes behind an individual IPv4
address.
6to4-integrated hosts MAY choose to time out a prefix entry if there
is no traffic for two valid lifetimes.
6to4-relays SHOULD address scaling for both traffic handling and NUD
exchanges.
6to4-relays MAY send prefix based redirects to provide load
balancing among relays or optimize routing symmetry.
Neighbor solicitation (type 135) is sent when the lifetime expires.
The 6to4-relay SHOULD answer if it is still willing to forward with
a Neighbor Advertisement (type 136) including the options defined
for redirect.
Security Considerations
While the 6to4 subnet appears to be a single logical link layer it
has an unusual characteristic where the members of the subnet are in
different administrative and trust domains. Despite this, this
document does not introduce any new security concerns, and attempts
to add some level of protection from spoofed redirects received over
the 6to4 interface. Basic protection from spoofed redirects is
provided unless the routing path infrastructure is penetrated.
Additional protection of the redirect is possible using IPsec. This
approach is not used by default, as the case where it is necessary
is rare, and the cost is relatively high.
Denial-of-Service attacks are possible on 6to4-routers by consuming
resources when they create INCOMPLETE state neighbor cache entries.
This problem can be mitigated by aggressively clearing the entry if
the state does not change due to valid traffic.
Hain Expires May 2001 11
6to4 router discovery and scaling November 2000
Protection from random Router Advertisements:
Simple spoof protection from random RA's is provided by passing a 16
bit random number through the RS / RA messages. This new option
effectively requires access to the packet path to generate a valid
spoof.
Protection from random redirects:
Simple spoof protection for redirects use the upper 16 bits of the
'Relay Ident' field (previously RESERVED) in the Redirected Header
option are used to reflect the Identifier field from the outer IPv4
header of the original RS packet. This combined with the original
packet contents mitigate guessing or flooding attacks, and virtually
require access to the packet path to generate a valid spoof.
References
1 [RFC-2026], Bradner, S., " The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
2 [6to4], Carpenter, B., "Connection of IPv6 Domains via IPv4
Clouds without Explicit Tunnels", draft-ietf-ngtrans-6to4-07.txt,
September 2000
3 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
4 [RFC 2491], Armitage, G., "IPv6 over Non-Broadcast Multiple
Access (NBMA) networks", RFC 2491, January 1999
5 [RFC 2373], Hinden, B., Deering, S., "IP Version 6 Addressing
Architecture", RFC 2373, July 1998
6 [6to4any], Huitema, C., "An anycast prefix for 6to4 relay
routers", draft-huitema-6to4anycast-00.txt, November 2000
7 [RFC 2526], Johnson, D., Deering, S., "Reserved IPv6 Subnet
Anycast Addresses", RFC 2526, March 1999
8 [ND], Narten, T., Nordmark, E., Simpson, W., "Neighbor Discovery
for IP Version 6", RFC 2461, December 1998
9 [routerreq] Baker, F., "Requirements for IP Version 4 Routers",
RFC-1812, June 1995
10 [mech], Nordmark, E., Gilligan, R. E., "Transition Mechanisms
for IPv6 Hosts and Routers", April 14, 2000
Hain Expires May 2001 12
Acknowledgments
Thanks for critique of this document provided by Christian Huitema,
David Thaler, Fred Baker and Brian Carpenter.
Author's Addresses
Tony Hain
Microsoft
One Microsoft Way
Redmond, Wa. USA 98052
Email: tonyhain@microsoft.com
Hain Expires May 2001 13
