One document matched: draft-hain-ipv6-rpf-icmp-00.xml
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629-fixed.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc5378 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5378.xml'>
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc subcompact="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes"?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<rfc category="std" docName="draft-hain-ipv6-rpf-icmp-00" ipr="pre5378Trust200902" obsoletes="" updates="" xml:lang="en" submissionType="IETF">
<front>
<title abbrev="IPv6 RPF ICMP">IPv6 Reverse Path Forwarding ICMP error message</title>
<author fullname="Tony Hain" initials="T." surname="Hain">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>500 108th Ave NE</street>
<street></street>
<city>Bellevue</city>
<region>WA</region>
<code>98004</code>
<country>USA</country>
</postal>
<phone>+1 425 468-1061</phone>
<email>alh-ietf@tndh.net</email>
</address>
</author>
<date day="15" month="Oct" year="2010" />
<abstract>
<t>This document specifies an icmp error message for use when the IPv6 source address has failed a reverse-path-forwarding (RPF) check. </t>
<t>The draft is being discussed on the ipv6@ietf.org list. </t>
</abstract>
<note title="Legal">
<t>This documents and the information contained therein 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.</t>
</note>
</front>
<middle>
<section title="Introduction" toc="default">
<t>A form of ingress traffic filtering commonly known as reverse path forwarding check is discussed in RFC 2827 <xref target="RFC2827" pageno="false" format="default"></xref>While the specific discussion in that document is focused on protecting against source address spoofing attacks by silently dropping the packets, there are instances when multi-homed IPv6 nodes have a mismatch between the source address and the selected path where the desired action SHOULD be to inform and provide a hint. This document defines an icmp error message to inform a source that the packet is being dropped because the source address used would not work as a destination for packets returning over this path. To avoid the situation where this informational back channel could be used as a denial of service attack, these icmp error messages MUST be rate limited.</t>
</section>
<section title="Terminology" toc="default">
<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" pageno="false" format="default">RFC 2119</xref>.</t>
</section>
<section title="Mechanisms" toc="default">
<section title="Overview" toc="default"></section>
<section title="ReversePathForwarding ICMP Error Message" toc="default">
<t>Informing the origin that the source prefix is not appropriate for the next hop as a symmetric return path.</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Source Prefix for this Path |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC-type | MAC-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Message Authentication Code |
+ +
| |
+ +
IPv6 Fields:
Destination Address
Copied from the Source Address field of the
invoking packet.
ICMPv6 Fields:
Type ???? --- 6
Code 0 - unsigned
1 - signed
Reserved 32-bit reserved field. Initialized to zero
for transmission; ignored on reception.
MAC-type 0 - unused
1 - HMAC-SHA1
2 - AES-CMAC
...
MAC-length Length of the message authentication option
MAC Value of the message authenticator
]]></artwork>
</figure>
<t>The optional authentication covers the source and destination address of this specific packet exchange, plus the return-via address.</t>
</section>
</section>
<section title="IANA Considerations" toc="default">
<t>This specification registers an IPv6 ICMP error message type</t>
</section>
<section title="Security Considerations" toc="default">
<t>The IPv6 ICMP RPF-error messages represents a potential denial of service attack vector, and therefore these messages MUST be rate limited by receivers.</t>
</section>
<section anchor="acks" title="Acknowledgements" toc="default">
<t>The general need for some way to inform multi-homed IPv6 nodes about an RPF check failure has been discussed in multiple sessions at IETF 77 and 78. </t>
</section>
<section anchor="comments" title="Pending comments" toc="default">
<t></t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list style="empty"><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 RFC 2119.</t></list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
<format octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt" type="TXT" />
<format octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html" type="HTML" />
<format octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" type="XML" />
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC2827">
<front>
<title abbrev="Deprecate RH0">Deprecation of Type 0 Routing Headers in IPv6
</title>
<author fullname="J. Abley" initials="J." surname="Abley">
<organization>Afilias</organization>
<address>
<postal>
<street>Suite 204, 4141 Yonge Street</street>
<street>Toronto, ON, CA</street>
<street>M2P 2A8</street>
</postal>
<phone>- +1 416 673 4176</phone>
<email>jabley@ca.afilias.info</email>
</address>
</author>
<date month="December" year="2007" />
<area>Internet</area>
<keyword>RH0</keyword>
<abstract>
<t>The functionality provided by IPv6's Type 0 Routing Header can be
exploited in order to achieve traffic amplification over a remote
path for the purposes of generating denial-of-service traffic. This
document updates the IPv6 specification to deprecate the use of IPv6
Type 0 Routing Headers, in light of this security concern.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5095" />
<format octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc5095.txt" type="TXT" />
<format octets="17491" target="http://xml.resource.org/public/rfc/html/rfc5095.html" type="HTML" />
<format octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc5095.xml" type="XML" />
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 17:00:47 |