One document matched: draft-thubert-3122bis-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC5072 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5072.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3122 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3122.xml">
<!ENTITY RFC3971 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971.xml">
<!ENTITY RFC3972 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-thubert-3122bis-00.txt" ipr="full3978" updates="3122">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="RFC3122bis">IPv6 Inverse Neighbor Discovery Update</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor">
<organization abbrev="Cisco">
Cisco Systems
</organization>
<address>
<postal>
<street>Village d'Entreprises Green Side</street>
<street>400, Avenue de Roumanille</street>
<street>Batiment T3</street>
<city>Biot - Sophia Antipolis</city>
<code>06410</code>
<country>FRANCE</country>
</postal>
<phone>+33 4 97 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author initials="E" surname="Levy-Abegnoli" fullname="Eric Levy-Abegnoli">
<organization abbrev="Cisco">
Cisco Systems
</organization>
<address>
<postal>
<street>Village d'Entreprises Green Side</street>
<street>400, Avenue de Roumanille</street>
<street>Batiment T3</street>
<city>Biot - Sophia Antipolis</city>
<code>06410</code>
<country>FRANCE</country>
</postal>
<phone>+33 4 97 23 26 20</phone>
<email>elevyabe@cisco.com</email>
</address>
</author>
<!-- Another author who claims to be an editor -->
<!--author fullname="Alex Conta" initials="A."
surname="Conta">
<organization>Transwitch Corporation </organization>
<address>
<postal>
<street> 3 Enterprise Drive</street>
<city>Shelton</city>
<region>CT</region>
<code>06484</code>
<country>USA</country>
</postal>
<email>aconta@txc.com</email>
</address>
</author -->
<date year="2008" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup></workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>Inverse Neighbor Discovery</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This draft updates the Inverse Discovery
Specification [RFC3122] to provide Secure Neighbor Discovery. The behaviour of
the protocol is slightly amended to enable an easier management of the addresses
on a link and enable Secure ND.</t>
</abstract>
</front>
<middle>
<section anchor='int' title="Introduction">
<t>This draft updates the <xref target="RFC3122"> Inverse Neighbor Discovery
Specification </xref>. Any behaviour
or format that is not explicitely changed is preserved. </t>
<t>The behaviour of the protocol is slightly amended :
<list style="symbols">
<t>Secure Inverse Neighbor Discovery is added for unicast
addresses with a 64bit interface ID.
This specification provides the additional options that are required to sign Inverse
ND messages with the properties that are defined in <xref target="RFC3971"/> and
details how they may be used to prove the ownership of advertised addresses.
</t>
<t>Fragmentation of ND messages is accepted but not required. <xref target="RFC3122"/>
requires the use of multiple Advertisement messages when the Target Address List
does not fit within MTU. With this specification, it is acceptable to fragment
a message, but it is still possible to use multiple Advertisement messages,
which can be necessary in particular in the context of Secure Inverse Neighbor
Discovery.
</t>
<t>
<xref target="RFC3122"/> does not allow a crisp management of all Addresses
that a peer may use on an interface. When multiple Advertisement messages are
used, it is possible to miss one and thus miss some information. With this
specification, Address Management is improved in such a way that it is possible
to advertise the addition or the deletion of a single address
and to get the exhaustive list of all the addresses that a neighbor might use
to source packets on an interface.
</t>
<t>With IPv4, Inverse ARP is traditionally applied to Point to Multipoint
networks only. <xref target="RFC3122"/> claims to apply to "Frame Relay networks",
and "also apply to other networks with similar behavior". This specification
extends the domain of applicability of Inverse Neighbor Discovery and provides
some additional information on how and why Inverse ND MAY be used on all types of
interface.
</t>
<t>Typos such as the length field in the Source/Target Address List are corrected.
</t>
</list>
</t>
<t>The concept of transaction is introduced to group multiple messages into
a single set to enable the advertisement of the complete list of all
addresses used to source packets on on an interface.
Whenever possible, a node should use one message per transaction.</t>
<t>
This is problematic when:
<list style="symbols">
<t>The list of addresses is so large that it causes the message to be larger than MTU
and the node can not fragment.
</t>
<t>Secure Inverse ND is applied and not all of the addresses are based on a same
CGA modifier (see <xref target="RFC3972"/>).
</t>
</list>
</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='indm' title="Inverse Neighbor Discovery Messages">
<t> This section updates the Inverse Neighbor Discovery Messages defined
in <xref target="RFC3122"/> section 2.
</t>
<t> A new field from the ICMP reserved part is used to indicate the version and
preserve backward compatibility. Version 0 is <xref target="RFC3122"/>.
Version 1 is this specification. A node proposes a version in the Inverse Neighbor
Discovery Solicitation Message and responds with the smallest of its own preferred
version and the received proposed version in an Advertisement. </t>
<t> Another new field from the ICMP reserved part is used to indicate the Transaction
ID of a Neighbor Discovery Solicitation Message, in order to correlate multiple
Advertisement messages that may result from one Solicitation Message. A sequence
number and a 'more' flag are also added to enable the soliciting node to check that
it actually received all the Advertisement messages for a given Transaction ID.
</t>
<section anchor='indsm' title="Inverse Neighbor Discovery Solicitation Message">
<t> The Inverse Neighbor Discovery Solicitation Message can be used to obtain
the full list of IPv6 addresses from the remote end of a Point to Point link
such as a PPP link, a tunnel or a Virtual Channel.
</t>
<t> The Inverse Neighbor Discovery Solicitation can also be used as a heartbeat
mechanism to verify whether a Point to Point link such as a tunnel
is still up when there is no signal from the lower layers to indicate a
failure.
</t>
<t> The Inverse Neighbor Discovery Solicitation Message is changed as follows:
</t>
<figure align="center" title="Modified Inverse Neighbor Discovery Solicitation Message">
<artwork align="left">
<![CDATA[
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Trans ID | Reserved |F| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
]]>
</artwork>
</figure>
<t>
This specification adds the following fields:
<list style="hanging">
<t hangText="Version:"> 8bit field.
Version of 0 indicates the support of <xref target="RFC3122"/> only.
Version of 1 indicates the desire to follow this specification
and the backward compatibility with version 0.
</t>
<t hangText="Transaction ID:">8bit field.
The Transaction ID is incremented with each Inverse Neighbor Discovery
Solicitation Message sent to the same neighbor. The transaction ID
can not be set to zero so it starts at 1 and wraps from 255 directly to 1.
</t>
<t hangText="F:"> 1bit field.
The "F" flag indicates a request of the Full List of addresses on the peer
side of the Link.
</t>
</list>
</t>
</section>
<section anchor="indam"
title="Inverse Neighbor Discovery Advertisement Message">
<t> The Inverse Neighbor Discovery Advertisement Message can be used as a response
to an Inverse Neighbor Discovery Solicitation Message or asynchronously at any
point of time once a first Inverse Neighbor Discovery Solicitation Message
was received indicating that the remote peer supports this specification.
</t>
<t>Multiple Inverse Neighbor Discovery Advertisement Messages might be needed
to report the full list of addresses. Those messages are correlated by a same
transaction ID and sequenced. All Messages but the last have the More bit set
to indicate that further Messages are to be expected for that transaction.</t>
<t>An unsolicited Advertisement is used to advertise the
addition or the deletion of a single address and is contained in a single
Inverse Neighbor Discovery Advertisement Message, with a transaction ID of 0.
</t>
<t> The Inverse Neighbor Discovery Advertisement Message is changed as follows:
</t>
<figure align="center" title="Modified Inverse Neighbor Discovery Advertisement Message">
<artwork align="left">
<![CDATA[
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Trans ID | Sequence |F|M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
]]>
</artwork>
</figure>
<t>
This specification adds the following fields:
<list style="hanging">
<t hangText="Sequence:"> 8bit field.
The sequence echoes that of the last received Inverse Neighbor
Discovery Solicitation Message.
</t>
<t hangText="Version:"> 8bit field.
Version of 0 indicates the support of <xref target="RFC3122"/> only.
Version of 1 indicates the desire to follow this specification.
Version can only be set to 1 if the Version in the Solicitation Message was 1 or above.
</t>
<t hangText="Transaction ID:">8bit field.
The Transaction ID echoes that of the Inverse Neighbor
Discovery Solicitation Message that this Message is responding to.
The transaction ID zero is used for unsolicited Advertisements.
</t>
<t hangText="Sequence:">8bit field.
The sequence is reset to zero for a new transaction ID and incremented
with each Advertisement Message sent to a same Neighbor for a same Transaction ID.
It is used to detect the loss of one Inverse Neighbor Discovery
Advertisement Message in a Transaction that involved multiple ones.
</t>
<t hangText="M:"> 1bit field.
The More "M" flag indicates that there are more messages for that transaction ID.
</t>
<t hangText="F:"> 1bit field.
The "F" flag indicates that the Full List of addresses will be provided for that
transaction.
</t>
</list>
</t>
<t>
Upon a request by the remote peer of the Full List of addresses, this node SHOULD
answer with all the addresses that can be used to reach it over this link in the
modified Target Address List.
</t>
<t>
If the IND Solicitation does not request the full list then his node MAY
answer with all the addresses that can be used to reach it over this link in the
modified Target Address List.
</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='indopt' title="Inverse Neighbor Discovery Options">
<t> This section updates the Inverse Neighbor Discovery Options defined
in <xref target="RFC3122"/> section 3.</t>
<section anchor='indoal' title="Source/Target Address List">
<t>
With this specification, the Source/Target Address List may be partial or full.
It can be used to indicate addition or deletion of indivisual addresses.
This new support can only be used once the first
Inverse Neighbor Discovery Solicitation Message is received from the remote peer
indicating the support of this specification.
</t>
<t>Until the Version that is supported by the peer is known, the only
Inverse Neighbor Discovery Messages that this node should send are
Solicitations, and this option if present can only be a Source Address List
option with a list of addresses that can be used to reach this node over this link.
</t>
<t> This specification uses a Length field of 8 bits, assuming that most
implementations of <xref target="RFC3122"/> also use a Length field of 8 bits
and that the misalignment in section 3.1 is commonly undestood as an undetected typo.
An error in reading the Length field can be detected when confronting the length
of the IPv6 packet and the expected length of this option.</t>
<t>
The Inverse Neighbor Discovery Advertisement Message is changed as follows:
</t>
<figure align="center" title="Modified Source/Target Address List option">
<artwork align="left">
<![CDATA[
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 | Length | Mode | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
~
|
+-+-+-+-+...
]]>
</artwork>
</figure>
<t>
This specification adds the following fields:
<list style="hanging">
<t hangText="Mode"> 8bit enumeration
<list style="hanging">
<t hangText="RFC3122:">Mode of 0 indicates that the list is built
conforming to <xref target="RFC3122"/>. All the addresses listed are usable
but the list might not be complete.
</t>
<t hangText="Full:">Mode of 1 indicates that the list might contain
addresses that are defined on another interface but may be used
to source or receive packets over this interface. This is the mode
that is used to in reply to a Solicitation with the "F" bit set.
</t>
<t hangText="Added:">Mode of 2 indicates that the list is a list of
recently added addresses but not necessarily part of a full report.
</t>
<t hangText="Deleted:">Mode of 3 indicates that the list is a list of
recently removed addresses that may no more be used on this link.
</t>
</list>
</t>
</list>
</t>
<t>Upon receiving an Address List, a node should verify that the addresses in the list
don't collide with any of its own address. In case it does, the duplicate address received
in the list will be ignored.
</t>
<t>When Secure IND is being used, all the addresses listed in the Target Address
List option in one Inverse Neighbor Discovery Advertisement Message must be based
on the same CGA modifier.
If multiple modifiers are used or some addresses were not built
based on CGA, then they must be split in multiple Inverse Neighbor Discovery
Advertisement Messages.
</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="SeND" title="Secure Inverse Neighbor Discovery">
<t>The list of addresses provided in Source/Target address list can be defended using the CGA
and the RSA options specified in [RFC3972] and [RFC3971]. However, in the case of Secure
Inverse Neighbor Discovery, several addresses announced in one message
(IND Solicitation or Advertisement) are
defended by a single CGA option and a single RSA option. That mandates that all addresses
in the list are based on CGA and were computed with the same modifier,
the same collision count, and the same security parameter sec.
In this case, the CGA option is as following:
<figure><artwork align="left"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Modifier (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subnet Prefix = 0 (8 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Col.Count = 0 | |
+-+-+-+-+-+-+-+-+ |
| |
~ Public Key (variable length) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Extension Fields (optional, variable length) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure></t>
<t>Since each address in the list is going to carry its own prefix (/64 if CGA is used),
the Subnet Prefix in the CGA option is set to zero. Therefore, it should not be checked by the
receiver against the prefix (/64 bits) of each CGA address found in the Address List.</t>
<t>The collision count is always zero, since no Duplicate Address Detection is performed, other
than the node ignoring peer addresses colliding with one of its own.</t>
<t>The remaining of the CGA algorithm, as described in [RFC3972] applies. The 16*Sec leftmost
bits of Hash2 should equal zero. Hash1 is computed separately for each address in the list,
using the first 64 bits as the Subnet Prefix, and the interface identifier should match Hash1
(except for bits 0, 1, 2, 6, and 7, which encode the collision count and the "u" and "g"
bits).</t>
<t>The RSA option must also be provided in the message, and the signature must verify with
the public key provided in the CGA option</t>
<t>In order to protect against replays, Timestamp and Nonce options, should also
be used in the message, with similar rules as one described in [RFC3971].
When the message is a solicitation (INS), it should have a nonce option.
When the message is sollicited (INA as a response to INS), it should repeat the nonce value
seen in the solicitation. As far as unsolicited message and solicitation, the timestamp option
is required.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor="inter" title="Interface Type and usages">
<t>Because of IPv4 and the ARP legacy, Inverse Neighbor Discovery is usually
associated to Point to Multipoint (P2MP) or Non-Broadcast Multi-Access (NBMA)
networks. And certainly, this specification is usable on such networks as
Frame Relay or Multidrop tunnels. </t>
<t>But the similarity with IPv4 is limited and this specification enables a lot
more: </t>
<section anchor="P2MP" title="Point to Multipoint Networks">
<t>
IPv6 Secure Inverse Neighbor Discovery can be applied to P2MP and NBMA
networks to prevent the theft an address by another Node.
</t>
</section>
<section anchor="P2P" title="Point-to-Point Links">
<t>As opposed to IPv4, using Inverse Neighbor Discovery makes a lot of sense
on Point-to-Point link such as PPP or tunnels:
</t>
<t>This specification inherits from <xref target="RFC3122"/> the support
of the authentication header to authenticate the remote peer on the link.
For P2P links, this might prove more relevant than Secure ND itself.
</t>
<t>Because IPv6 operates purely at layer 3, the PPP Network Control Protocol for IPv6
defined in <xref target="RFC5072"/> provides a way to negotiate a unique, 64bit
interface identifier to be used for the address autoconfiguration
but does not enable to advertise an IPv6 address. This would not fit anyway since
IPv6 might use many addresses of various lifetimes on a same interface.
This specification provides the means to create and maintain the list of addresses
that can be used to reach the remote peer at any point of time.
</t>
<t>A number of Denial of Service attacks are documented when using
<xref target="RFC4861"/> by
sending packets to addresses that are not assigned but belong to a prefix
that is associated to the P2P link.
On those links, Inverse Neighbor Discovery enables a proactive model
that defeats those attacks. Any packet that is received for a destination
that is not in the ND table is simply dropped.</t>
</section>
<section anchor="transit" title="Broadcast Networks">
<t>A multihomed host attached to a broadcast network might use an address that
belongs to another interface on another subnet to source a packet. This makes the
validation of source addresses very problematic. With this specification, a router
may solicit the full list of all addreses that this host might use to source packets
on that interface, and prove the ownership using SeND. The router might then
accept packets that are sourced off-link and may install a host route to that address.
</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This draft improves the security model in <xref target="RFC3122"/> by adding the
capability to use Secure Neighbor Discovery</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC2460;
&RFC3122;
&RFC3971;
&RFC3972;
&RFC4861;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC2629;
&RFC5072;
</references>
<!-- Change Log
<section anchor="app-additional" title="Additional Stuff">
<t>This becomes an Appendix.</t>
</section>
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems). -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 03:24:15 |