INTERNET-DRAFT F. Templin
Nokia
Expires 25 April 2003 25 October 2002
Neighbor Affiliation Protocol for IPv6-over-(foo)-over-IPv4
draft-templin-v6v4-ndisc-00.txt
Abstract
This document proposes extensions to IPv6 Neighbor Discovery for
IPv6-over-(foo)-over-IPv4 links, where (foo) is either an
encapsulating layer (e.g., UDP) or a NULL layer. It is essentially a
lightweight, link-layer mechanism for nodes and routers to establish
security associations, discover and dynamically re-adjust maximum
transmission units, and perform neighbor unreachability detection.
The protocol makes no attempt to ensure reliable message delivery;
this function is performed by higher-layer protocols, e.g. TCP.
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Templin Expires 25 April 2003 [Page 1]
INTERNET-DRAFT V6-V4 Neighbor Affiliation 25 October 2002
1. Introduction
The author anticipates a long-term requirement for [IPv6] operation
over IPv6-over-(foo)-over-IPv4 links, where IPv4 is treated as a link
layer for IPv6-over-(foo). Neighbors that exchange data over such
links will need to make the most efficient, robust and secure use of
the intervening [IPv4] paths possible. The author believes that this
will require link-layer specific extensions to enable a hybrid proac-
tive/on-demand neighbor discovery mechanism using bi-directional
links.
IPv6 nodes and IPv6 routers will need to establish security associa-
tions, determine and dynamically re-adjust maximum transmission
units, and perform neighbor unreachability detection using an IPv4
intranet or internet as the link layer. Although IPv4 fragmentation
is considered harmful [FRAG][FOLK], the author believes that strate-
gically adapting to, and minimizing, fragmentation can provide a
superior solution to strict fragmentation avoidance. Central to the
design goals is the ability to establish and maintain lightweight,
link-layer associations between IPv6 neighbors to provide a feedback
loop. Although these associations take on certain aspects of connec-
tion-oriented protocols, the author prefers the term "neighbor affil-
iation".
2. Applicability Statement
- proposes a neighbor affiliation protocol for IPv6 nodes and routers
- may be useful for IPv6 operations in certain deployment scenarios
3. Terminology
The terminology of [IPv4] and [IPv6] apply to this document. The fol-
lowing additional term is defined:
neighbor affiliation:
a lightweight association between IPv6 neighbors
4. Neighbor Affiliation
[DISC] specifies mechanisms for IPv6 nodes to discover and maintain
reachability information about active neighbors. Neighbor Solicitaion
(NS) and Neighbor Advertisement (NA) messages are normally used for
this purpose on multiple access, broadcast media. But, when an IPv4
Templin Expires 25 April 2003 [Page 2]
INTERNET-DRAFT V6-V4 Neighbor Affiliation 25 October 2002
intranet/internet is used as the link layer, the underlying network
is treated as a non-broadcast multiple access (NBMA) media for IPv6,
and the standard usage for NS and NA messages specified in [DISC]
does not apply. Thus, an adaptation for the use of these messages for
IPv6-over-(foo)-over-IPv4 links is specified in this document.
When multiple IPv4 hops intervene between nodes, [DISC] provides no
trust basis nor any clear means for the node to monitor the router's
liveliness, i.e., multicast is not supported. Additionally, the path
MTU between any two nodes may differ considerably. [FRAG, 3.4] speaks
favorably for the use of transparent fragmentation, i.e., the use of
reliable fragmentation and reassembly at a layer below IP. What is
proposed here is not a firm reliance on such link layer fragmenta-
tion, but judicious and minimal use so that network utilization can
be maximized while fragmentation is minimized.
Since the intervening IPv4 path between nodes is likely to be uni-
cast-only, we consider only the use of unicast NS/NA messages for
now. These messages are formatted as specified in [DISC, 4.3-4] and
always include the source/target link layer address options as appro-
priate for unicast operation. But, as permitted in [DISC, 4.6.1],
this document specifies the content and format of the link-layer
address for IPv6-over-(foo)-over-IPv4.
The neighbor affiliation proposal entails the following roughly-spec-
ified algorithm:
1) The source node creates a unicast IPv6 NS and wraps it in
a (foo)/IPv4 header. The IPv4 length MAY BE artificially
inflated to the size of the outgoing link's physical MTU
if path probing is needed (i.e., the packet is NULL-padded
beyond the encapsulated RS). The the DF flag is NOT set in
the IPv4 header. The source link layer address field contains
a "SYN" indication (format TBD). The NS is then sent to
the target node, and a state variable for the target
transitions from "CLOSED" to "NS-SENT"
2) The target node looks for either full IPv6 NS's or
IPv4 first-fragments arriving in the reassembly cache (by
any means necessary). If the first-fragment contains a unicast
NS, and if the "SYN" bit is set, the IPv4 length of the fragment
indicates the path MTU from the initiating neighbor. (Any other
fragments arriving for the IPv4 packet can be discarded.) The
receiver (which was in the "LISTEN" state) creates a state
variable in the "NS-RECEIVED" for the initiator, then sends
a unicast NA to the host with a "Source->Target Path MTU"
value and a "SYN/ACK" indication encoded in the target link
layer address (format TBD) using the first fragment's length
Templin Expires 25 April 2003 [Page 3]
INTERNET-DRAFT V6-V4 Neighbor Affiliation 25 October 2002
as the path MTU value. The IPv4 length MAY BE artificially
inflated to the size of the target's outgoing link (as for
the NS in step 1) if path probing is needed
3) The source node receives the NA, by snooping incoming
IPv4 first-fragments as described above, looks for the
"SYN/ACK" indication, places the length from the
"Source->Target Path MTU" field in the destination cache
for the target, and transitions from the "NS-SENT" state
to the "ESTABLISHED" state. It then creates a NA message (as
in 2) which it sends to the target; placing the length of the
first-fragment in the "Target->Source Path MTU" field and an
"ACK" indication encoded in the source/target link layer
address option (format TBD).
4) The target receives the NA message and transitions from the
"NS-RECEIVED" state to the "ESTABLISED" state. It writes the
value in the Target->Source Path MTU option into a destination
cache entry for the source. The target and source have now
established a bi-directional link, using the exact mechanism
specified in [TCP, 3.4]
NOTES:
- If either end of the affiliation is unable to "snoop" the
reassembly cache in the manner specified above, it must return
a minimum path MTU value to the peer that is no smaller than
the IPv6 MINMTU of 1280 and no larger than can be reasonably
expected to avoid fragmentation (TBD)
- If either end of the affiliation chooses not to probe the
path, it should set a "not probing" indication in the NS/NA
message (TBD)
- If either end of the affiliation detects fragmentation of data
packets at any time, it must send a "fragmentation experienced'
indication in an unsolicited NA message to inform the other end
of the new path MTU
- If fragmentation continues, "fragmentation experienced" messages
are scheduled to avoid congestion on the return path (i.e.,
they are sent according to some TBD scheduling algorithm; not
on receipt of each fragmented packet)
Left to consider is the fact that "keepalives" are needed to keep the
affiliation strong. This is done through data packets sent between
the source and target. Packets between the source and target need to
carry a "RECENTLY_HEARD" indication signifying that each end of the
Templin Expires 25 April 2003 [Page 4]
INTERNET-DRAFT V6-V4 Neighbor Affiliation 25 October 2002
affiliation is hearing periodic messages from the other. When one end
of the affiliation has no data packets to send within a "NEIGH-
BOR_KEEPALIVE" timeout, it sends an unsolicited NA to the other end
if it wishes to keep the affiliation alive. When one end of the affi-
laition ceases to hear periodic messages from the other end for a
"NEIGHBOR_LOST" timeout period, it enters the CLOSED state and either
sends a new NS to re-establish the affiliation or remains quiet
unless/until new data packet are Lastly, but most importantly, *all*
packets are sent with the DF flag NOT set; if either end of the
affiliation detects fragmentation, an unsolicited NA is sent with the
newly-detected (reduced) path MTU in the MTU option to inform the
peer.
Nodes may employee a strategy for allowing/disallowing particular
affiliations, e.g., a router may choose not to answer a solicitation
from a new host if its state cache is nearly full. Finally, security
measures should be taken to ensure that the affiliation protocol
described above is not abused by malicious nodes. Candidate mecha-
nisms might be an adaptation of TCP "syn cookies" [reference needed]
or a shared secret between the neighbors.
5. IANA considerations
TBD
6. Security considerations
TBD
Acknowledgements
The proposal herin is nearly identical to some presented on the [TCP-
IP] [MTUDWG] mailing lists, roughly between the period of May 1997
through May 1990. The original proposal that most closely matches the
one herein was offered by Charles Lynn on November 17, 1987.
Earlier works from SRI International propsed a "router affiliation"
protocol. The term "affiliation" as used in this document was
directly derived from its use in those earlier works. Two SRI
researchers who participated in this effort were Barbara Denny and
Bob Gilligan.
The author would finally like to acknowledge the founding architects
of the DARPA Internet protocols, who created the technologies used by
the millions of nodes on the Internet today and the billions more to
come in the forseeable future.
Templin Expires 25 April 2003 [Page 5]
INTERNET-DRAFT V6-V4 Neighbor Affiliation 25 October 2002
Normative References
[IPv4] Postel, J., "Internet Protocol", RFC 791.
[TCP] Postel, J., "Transmission Control Protocol", RFC 793.
[IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460.
[DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[FRAG] Kent, C., and J. Mogul, "Fragmentation Considered
Harmful", December, 1987
[FOLK] Shannon, C., Moore, D. and k claffy, "Beyond Folklore:
Observations on Fragmented Traffic"
[PROBE] Mogul, J., Kent, C., Partridge, C., and K. McCloughrie,
"IP MTU Discovery Options", RFC 1063, July 1988.
[PMTUD] Mogul, J. and S. Deering, "Path MTU Discovery",
RFC 1191, November 1990.
[MTUDWG] IETF MTU Discovery Working group mailing list,
gatekeeper.dec.com/pub/DEC/WRL/mogul/mtudwg-log,
November 1989 - February 1995.
[TCP-IP] TCP-IP Mailing list archives,
http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip,
May 1987 - May 1990.
Informative References
Authors Addresses
Fred L. Templin
Nokia
313 Fairchild Drive
Mountain View, CA, USA
Phone: (650)-625-2331
Email: ftemplin@iprg.nokia.com
Templin Expires 25 April 2003 [Page 6]