draft-ietf-l2vpn-arp-mediation-18.txt   draft-ietf-l2vpn-arp-mediation-19.txt 
L2VPN Working Group Himanshu Shah(Ciena) L2VPN Working Group Himanshu Shah(Ciena)
Intended Status: Proposed Standard Eric Rosen(Cisco) Intended Status: Proposed Standard Eric Rosen(Cisco)
Internet Draft Giles Heron(Cisco) Internet Draft Giles Heron(Cisco)
Expires: April 24, 2012 Vach Kompella(Alcatel-Lucent) Expires: July 10, 2012 Vach Kompella(Alcatel-Lucent)
October 24 2011 January 10 2012
ARP Mediation for IP Interworking of Layer 2 VPN ARP Mediation for IP Interworking of Layer 2 VPN
draft-ietf-l2vpn-arp-mediation-18.txt draft-ietf-l2vpn-arp-mediation-19.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work Drafts as reference material or to cite them other than as "work
in progress." in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 24, 2012 This Internet-Draft will expire on July 10, 2012
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided in Section 4.e of the Trust Legal Provisions and are provided
skipping to change at page 2, line 40 skipping to change at page 2, line 40
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described "OPTIONAL" in this document are to be interpreted as described
in [RFC2119]. in [RFC2119].
Table of Contents Table of Contents
Copyright Notice............................................ 1 Copyright Notice........................................... 1
1. Introduction................................................ 4 1. Introduction............................................... 4
2. ARP Mediation (AM) function................................. 6 2. ARP Mediation (AM) function................................ 6
3. IP Layer 2 Interworking Circuit............................. 7 3. IP Layer 2 Interworking Circuit............................ 7
4. IP Address Discovery Mechanisms............................. 7 4. IP Address Discovery Mechanisms............................ 7
4.1. Discovery of IP Addresses of Locally Attached IPv4 CE.. 8 4.1. Discovery of IP Addresses of Locally Attached IPv4 CE. 8
4.1.1. Monitoring Local Traffic.......................... 8 4.1.1. Monitoring Local Traffic......................... 8
4.1.2. CE Devices Using ARP.............................. 8 4.1.2. CE Devices Using ARP............................. 8
4.1.3. CE Devices Using Inverse ARP..................... 10 4.1.3. CE Devices Using Inverse ARP.................... 10
4.1.4. CE Devices Using PPP............................. 10 4.1.4. CE Devices Using PPP............................ 10
4.1.5. Router Discovery method.......................... 11 4.1.5. Router Discovery method......................... 11
4.1.6. Manual Configuration............................. 12 4.1.6. Manual Configuration............................ 12
4.2. How a CE Learns the IPv4 address of a remote CE....... 12 4.2. How a CE Learns the IPv4 address of a remote CE...... 12
4.2.1. CE Devices Using ARP............................. 12 4.2.1. CE Devices Using ARP............................ 12
4.2.2. CE Devices Using Inverse ARP..................... 13 4.2.2. CE Devices Using Inverse ARP.................... 13
4.2.3. CE Devices Using PPP............................. 13 4.2.3. CE Devices Using PPP............................ 13
4.3. Discovery of IP Addresses of IPv6 CE Devices.......... 13 4.3. Discovery of IP Addresses of IPv6 CE Devices......... 13
4.3.1. Distinguishing Factors Between IPv4 and IPv6..... 13 4.3.1. Distinguishing Factors Between IPv4 and IPv6.... 13
4.3.2. Requirements for PEs............................. 14 4.3.2. Requirements for PEs............................ 14
4.3.3. Processing of Neighbor Solicitations............. 14 4.3.3. Processing of Neighbor Solicitations............ 15
4.3.4. Processing of Neighbor Advertisements............ 15 4.3.4. Processing of Neighbor Advertisements........... 15
4.3.5. Processing Inverse Neighbor Solicitations (INS).. 16 4.3.5. Processing Inverse Neighbor Solicitations (INS). 16
4.3.6. Processing of Inverse Neighbor Advertisements (INA)17 4.3.6. Processing of Inverse Neighbor Advertisements .. 17
4.3.7. Processing of Router Solicitations............... 18 4.3.7. Processing of Router Solicitations.............. 18
4.3.8. Processing of Router Advertisements.............. 18 4.3.8. Processing of Router Advertisements............. 18
4.3.9. Duplicate Address Detection...................... 18 4.3.9. Duplicate Address Detection..................... 18
4.3.10. CE address discovery for CEs attached using PPP. 19 4.3.10. CE address discovery for CEs attached using PPP 19
5. CE IPv4 Address Signaling between PEs...................... 19 5. CE IPv4 Address Signaling between PEs..................... 19
5.1. When to Signal an IPv4 address of a CE................ 19 5.1. When to Signal an IPv4 address of a CE............... 19
5.2. LDP Based Distribution of CE IPv4 Addresses........... 20 5.2. LDP Based Distribution of CE IPv4 Addresses.......... 20
6. IPv6 Capability Advertisement.............................. 23 6. IPv6 Capability Advertisement............................. 22
6.1. PW Operational Down on Stack Capability Mis-Match..... 24 6.1. PW Operational Down on Stack Capability Mis-Match.... 23
6.2. Stack Capability Fall-back............................ 24 6.2. Stack Capability Fall-back........................... 24
7. IANA Considerations........................................ 25 7. IANA Considerations....................................... 25
7.1. LDP Status messages................................... 25 7.1. LDP Status messages.................................. 25
7.2. Interface Parameters.................................. 25 7.2. Interface Parameters................................. 25
8. Security Considerations.................................... 26 8. Security Considerations................................... 26
8.1. Control Plane Security................................ 26 8.1. Control Plane Security............................... 26
8.2. Data plane security................................... 27 8.2. Data plane security.................................. 27
9. Acknowledgements........................................... 27 9. Acknowledgements.......................................... 27
10. References................................................ 28 10. References............................................... 27
10.1. Normative References................................. 28 10.1. Normative References................................ 27
10.2. Informative References............................... 29 10.2. Informative References.............................. 29
11. Authors' Addresses........................................ 30 11. Authors' Addresses....................................... 29
APPENDIX A:................................................... 32 APPENDIX A:.................................................. 32
A.1. Use of IGPs with IP L2 Interworking L2VPNs............ 32 A.1. Use of IGPs with IP L2 Interworking L2VPNs........... 32
A.1.1. OSPF............................................. 32 A.1.1. OSPF............................................ 32
A.1.2. RIP.............................................. 33 A.1.2. RIP............................................. 33
A.1.3. IS-IS............................................ 33 A.1.3. IS-IS........................................... 33
1. Introduction 1. Introduction
Layer 2 Virtual Private Networks (L2VPN) are constructed over a Layer 2 Virtual Private Networks (L2VPN) are constructed over a
Service Provider IP/MPLS backbone but are presented to the Service Provider IP/MPLS backbone but are presented to the
Customer Edge (CE) devices as Layer 2 networks. In theory, Customer Edge (CE) devices as Layer 2 networks. In theory,
L2VPNs can carry any Layer 3 protocol, but in many cases, the L2VPNs can carry any Layer 3 protocol, but in many cases, the
Layer 3 protocol is IP. Thus it makes sense to consider Layer 3 protocol is IP. Thus it makes sense to consider
procedures that are optimized for IP. procedures that are optimized for IP.
skipping to change at page 6, line 34 skipping to change at page 6, line 34
remote CE. remote CE.
5. Respond appropriately to ARP and Inverse ARP requests from 5. Respond appropriately to ARP and Inverse ARP requests from
the local CE device, using IP address of the remote CE and the local CE device, using IP address of the remote CE and
the hardware address of the local PE. the hardware address of the local PE.
A PE that is to perform ARP Mediation for IPv6 packets SHOULD A PE that is to perform ARP Mediation for IPv6 packets SHOULD
perform the following logical steps: perform the following logical steps:
1. Discover the IPv6 addresses of the locally attached CE device, 1. Discover the IPv6 addresses of the locally attached CE device,
together with those of the remote CE device. together with those of the remote CE device.
2. Intercept Neighbor Discovery and Inverse Neighbor Discovery 2.
packets received from the local CE device, learning a. Intercept Neighbor Discovery (ND) and Inverse Neighbor
information about the IPv6 configuration of the CE, before Discovery (IND) packets received from the local CE
forwarding the packets over the pseudowire to the remote PE. device.
b. From these NB and IND packets learn the IPv6
configuration of the CE.
c. Forward the ND and IND packets over the pseudowire to the
remote PE.
3. Intercept Neighbor Discovery and Inverse Neighbor Discovery 3. Intercept Neighbor Discovery and Inverse Neighbor Discovery
packets received over the pseudowire from the remote PE, packets received over the pseudowire from the remote PE,
possibly modifying them (if required for the type of outgoing possibly modifying them (if required for the type of outgoing
AC) before forwarding to the local CE, and also learning AC) before forwarding to the local CE, and also learning
information about the IPv6 configuration of the remote CE. information about the IPv6 configuration of the remote CE.
PEs MUST support ARP mediation for IPv4 L2 Interworking
circuits. PEs SHOULD support ARP mediation for IPv6 L2
interworking circuits.
Details for the above-described procedures are given in the Details for the above-described procedures are given in the
following sections. following sections.
3. IP Layer 2 Interworking Circuit 3. IP Layer 2 Interworking Circuit
The IP Layer 2 interworking Circuit refers to interconnection of The IP Layer 2 interworking Circuit refers to interconnection of
the Attachment Circuit with the IP Layer 2 Transport pseudowire the Attachment Circuit with the IP Layer 2 Transport pseudowire
that carries IP datagrams as the payload. The ingress PE removes that carries IP datagrams as the payload. The ingress PE removes
the data link header of its local Attachment Circuit and the data link header of its local Attachment Circuit and
transmits the payload (an IP packet) over the pseudowire with or transmits the payload (an IP packet) over the pseudowire with or
without the optional control word. In some cases, multiple data without the optional control word. If the IP packet arrives at
link headers may exist, such as a bridged Ethernet PDU on an ATM the ingress PE with multiple data link headers (for example in
Attachment Circuit. In this case, all data link headers are the case of bridged Ethernet PDU on an ATM Attachment Circuit),
removed to expose the IP packet at the ingress. The egress PE all data link headers MUST be removed from the IP packet before
encapsulates the IP packet with the data link header used on its transmission over the PW. The egress PE encapsulates the IP
local Attachment Circuit. packet with the data link header used on its local Attachment
Circuit.
The encapsulation for the IP Layer 2 Transport pseudowire is The encapsulation for the IP Layer 2 Transport pseudowire is
described in [RFC4447]. The "IP Layer 2 interworking circuit" described in [RFC4447]. The "IP Layer 2 interworking circuit"
pseudowire is also referred to as "IP pseudowire" in this pseudowire is also referred to as "IP pseudowire" in this
document. document.
In the case of an IPv6 L2 Interworking Circuit, the egress PE In the case of an IPv6 L2 Interworking Circuit, the egress PE
MAY modify the contents of Neighbor Discovery or Inverse MAY modify the contents of Neighbor Discovery or Inverse
Neighbor Discovery packets before encapsulating the IP packet Neighbor Discovery packets before encapsulating the IP packet
with the data link header. with the data link header.
skipping to change at page 9, line 21 skipping to change at page 9, line 25
selection could be based on manual configuration or the PE MAY selection could be based on manual configuration or the PE MAY
optionally use the following selection criteria. In either case, optionally use the following selection criteria. In either case,
manual configuration of the IP address of the local CE (and its manual configuration of the IP address of the local CE (and its
MAC address) MUST be supported. MAC address) MUST be supported.
o Wait to learn the IP address of the remote CE (through PW o Wait to learn the IP address of the remote CE (through PW
signaling) and then select the local CE that is sending signaling) and then select the local CE that is sending
the request for IP address of the remote CE. the request for IP address of the remote CE.
o Augment cross checking with the local IP address learned o Augment cross checking with the local IP address learned
through listening for link local multicast packets (as per through listening for link local multicast packets (as per
section 4.1.1 above). section 4.1.1. above).
o Augment cross checking with the local IP address learned o Augment cross checking with the local IP address learned
through the Router Discovery protocol (as described below through the Router Discovery protocol (as described below
in section 4.1.5). in section 4.1.5. ).
o There is still a possibility that the local PE may not o There is still a possibility that the local PE may not
receive an IP address advertisement from the remote PE and receive an IP address advertisement from the remote PE and
there may exist multiple local IP routers that attempt to there may exist multiple local IP routers that attempt to
'connect' to remote CEs. In this situation, the local PE 'connect' to remote CEs. In this situation, the local PE
MAY use some other criteria to select one IP device from MAY use some other criteria to select one IP device from
many (such as "the first ARP received"), or an operator many (such as "the first ARP received"), or an operator
MAY configure the IP address of the local CE. Note that MAY configure the IP address of the local CE. Note that
the operator does not have to configure the IP address of the operator does not have to configure the IP address of
the remote CE (as that would be learned through pseudowire the remote CE (as that would be learned through pseudowire
signaling). signaling).
skipping to change at page 10, line 32 skipping to change at page 10, line 38
is known. If the PE does not yet have the IP address of the is known. If the PE does not yet have the IP address of the
remote CE, it does not respond, but records the IP address of remote CE, it does not respond, but records the IP address of
the local CE and the circuit information. Subsequently, when the the local CE and the circuit information. Subsequently, when the
IP address of the remote CE becomes available, the PE MAY IP address of the remote CE becomes available, the PE MAY
initiate an Inverse ARP request as a means of notifying the IP initiate an Inverse ARP request as a means of notifying the IP
address of the remote CE to the local CE. address of the remote CE to the local CE.
This is the typical mode of operation for Frame Relay and ATM This is the typical mode of operation for Frame Relay and ATM
Attachment Circuits. If the CE does not use Inverse ARP, the PE Attachment Circuits. If the CE does not use Inverse ARP, the PE
can still discover the IP address of the local CE using the can still discover the IP address of the local CE using the
mechanisms described in section 4.1.1 and 4.1.5. mechanisms described in section 4.1.1. and 4.1.5.
4.1.4. CE Devices Using PPP 4.1.4. CE Devices Using PPP
The IP Control Protocol [RFC1332] describes a procedure to The IP Control Protocol [RFC1332] describes a procedure to
establish and configure IP on a point-to-point connection, establish and configure IP on a point-to-point connection,
including the negotiation of IP addresses. When such an including the negotiation of IP addresses. When such an
Attachment Circuit is configured for IP interworking, PPP Attachment Circuit is configured for IP interworking, PPP
negotiation is not performed end-to-end between CE devices. negotiation is not performed end-to-end between CE devices.
Instead, PPP negotiation takes place between the CE and its Instead, PPP negotiation takes place between the CE and its
local PE. The PE performs proxy PPP negotiation and informs the local PE. The PE performs proxy PPP negotiation and informs the
skipping to change at page 11, line 19 skipping to change at page 11, line 24
IP address is zero, the PE responds with Configure-Reject IP address is zero, the PE responds with Configure-Reject
(as this is a request from the CE to assign it an IP (as this is a request from the CE to assign it an IP
address). Also, the IP address option is set with zero address). Also, the IP address option is set with zero
value in the Configure-Reject response to instruct the CE value in the Configure-Reject response to instruct the CE
not to include that option in any subsequent Configure- not to include that option in any subsequent Configure-
Request. Request.
o If the PE receives a Configure-Request without the IP- o If the PE receives a Configure-Request without the IP-
Address option, it responds with a Configure-Ack. In this Address option, it responds with a Configure-Ack. In this
case the PE is unable to learn the IP address of the local case the PE is unable to learn the IP address of the local
CE using IPCP and hence MUST rely on other means as CE using IPCP and hence MUST rely on other means as
described in sections 4.1.1 and 4.1.5. Note that in described in sections 4.1.1. and 4.1.5. Note that in
order to employ other learning mechanisms, the IPCP order to employ other learning mechanisms, the IPCP
negotiations MUST have reached the open state. negotiations MUST have reached the open state.
o If the PE does not know the IP address of the remote CE, o If the PE does not know the IP address of the remote CE,
it sends a Configure-Request without the IP-Address it sends a Configure-Request without the IP-Address
option. option.
o If the PE knows the IP address of the remote CE, it sends o If the PE knows the IP address of the remote CE, it sends
a Configure-Request with the IP-Address option containing a Configure-Request with the IP-Address option containing
the IP address of the remote CE. the IP address of the remote CE.
The IPCP IP-Address option MAY be negotiated between the PE and The IPCP IP-Address option MAY be negotiated between the PE and
skipping to change at page 12, line 4 skipping to change at page 12, line 10
In order to learn the IP address of the CE device for a given In order to learn the IP address of the CE device for a given
Attachment Circuit, the PE device MAY execute Router Discovery Attachment Circuit, the PE device MAY execute Router Discovery
Protocol [RFC1256] whereby a Router Discovery Request (ICMP - Protocol [RFC1256] whereby a Router Discovery Request (ICMP -
router solicitation) message is sent using a source IP address router solicitation) message is sent using a source IP address
of zero. The IP address of the CE device is extracted from the of zero. The IP address of the CE device is extracted from the
Router Discovery Response (ICMP - router advertisement) message Router Discovery Response (ICMP - router advertisement) message
from the CE. It is possible that the response contains more than from the CE. It is possible that the response contains more than
one router addresses with the same preference level; in which one router addresses with the same preference level; in which
case, some heuristics (such as first on the list) are necessary. case, some heuristics (such as first on the list) are necessary.
The use of the Router Discovery method by the PE is optional. The use of the Router Discovery method by the PE is optional.
4.1.6. Manual Configuration 4.1.6. Manual Configuration
In some cases, it may not be possible to discover the IP address In some cases, it may not be possible to discover the IP address
of the local CE device using the mechanisms described in of the local CE device using the mechanisms described in
sections 4.1.1 - 4.1.5 above. In such cases manual configuration sections 4.1 - 4.1.5 above. In such cases manual configuration
MAY be used. All implementations of this document MUST support MAY be used. All implementations of this document MUST support
manual configuration of the IPv4 address of the local CE. This manual configuration of the IPv4 address of the local CE. This
is the only REQUIRED mode for a PE to support. is the only REQUIRED mode for a PE to support.
The support for configuration of the IP address of the remote CE The support for configuration of the IP address of the remote CE
is OPTIONAL. is OPTIONAL.
4.2. How a CE Learns the IPv4 address of a remote CE 4.2. How a CE Learns the IPv4 address of a remote CE
Once the local PE has received the IP address information of the Once the local PE has received the IP address information of the
skipping to change at page 21, line 39 skipping to change at page 21, line 41
procedures described in Section 6 below. In addition, by procedures described in Section 6 below. In addition, by
virtue of not setting the manual configuration for IPv4 virtue of not setting the manual configuration for IPv4
support, an IPv6 only support is realized. support, an IPv6 only support is realized.
We use the Address List TLV [RFC5036] to signal the IPv4 address We use the Address List TLV [RFC5036] to signal the IPv4 address
of the local CE. This IP Address List TLV is included in the of the local CE. This IP Address List TLV is included in the
optional parameter field of the Label Mapping message. optional parameter field of the Label Mapping message.
The Address List TLV is only used for IPv4 addresses. The Address List TLV is only used for IPv4 addresses.
The encoding of the IP Address List TLV is: The fields of the IP Address List TLV are set as follows:
Length Length
6 bytes: 2 bytes for address family and 4 bytes of IPv4 Set to 6 to encompass 2 bytes of Address Family field and 4
address. bytes of Addresses field (because a single IPv4 address is
used).
Address Family Address Family
Two octet quantity containing a value from the ADDRESS Set to 1 to indicate IPv4 as defined in [RFC5036].
FAMILY NUMBERS in [RFC3232] that encodes the address
contained in the Address field.
IP Address of CE
IPv4 address of the CE attached to the advertising PE. The
encoding of the individual address depends on the Address
Family (which may be of value zero).
The following address encodings are defined by this version of
the protocol:
Address Family Address Encoding
IPv4 (1) 4 octet full IPv4 address Addresses
Contains a single IPv4 address that is the address of the
CE attached to the advertising PE.
The IP address field is set to all zeroes to denote that the The address in the Addresses field is set to all zeros to denote
advertising PE has not learned the IPv4 address of its local CE. that the advertising PE has not learned the IPv4 address of its
Any non-zero value of the IP address field denotes the IPv4 local CE. Any non-zero address value denotes the IPv4 address of
address of the advertising PE's attached CE device. the advertising PE's attached CE device.
The IPv4 address of the CE is also supplied in the optional The IPv4 address of the CE is also supplied in the optional
parameters field of the LDP Notification message along with the parameters field of the LDP Notification message along with the
PW FEC. The LDP Notification message is used to signal any PW FEC. The LDP Notification message is used to signal any
change in the status of the CE's IPv4 address. change in the status of the CE's IPv4 address.
The encoding of the LDP Notification message is as follows. The encoding of the LDP Notification message is as follows.
0 1 2 3 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 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
skipping to change at page 23, line 28 skipping to change at page 23, line 21
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter ID | Length | Stack Capability | | Parameter ID | Length | Stack Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter ID = 0x16 Parameter ID = 0x16
Length = 4 Length = 4
Stack Capability = bitmask 0x0001 indicates IPv6 stack capability The Stack Capability field is a bit field. Only one bit is
defined in this document. When bit zero (the least significant
bit with bitmask 0x0001) is set, it indicates IPv6 stack
capability.
The presence of stack capability TLV is relevant only when the The presence of stack capability TLV is relevant only when the
PW type is IP PW. Setting of the bitmask to value of 0x0001 PW type is IP PW. A PE that supports the IPv6 on an IP PW MUST
indicates IPv6 stack capability. signal the Stack Capability sub-TLV in the initial Label Mapping
message for the PW. The PE nodes compare the value advertised by
A PE that supports IPv6 on an IP PW MUST signal the Stack the remote PE with the local configuration and only use a
Capability sub-TLV in the initial Label Mapping message for the capability which is supported by both.
PW. The PE nodes compare the value advertised by the remote PE
with the local configuration and only use a capability which is
supported by both.
The behavior of a PE that does not understand an Interface The behavior of a PE that does not understand an Interface
Parameter sub-TLV is specified in section 5.5 of RFC 4447 Parameter sub-TLV is specified in section 5.5 of RFC 4447
[RFC4447]. [RFC4447].
In some deployment scenarios, it may be desirable to take a PW In some deployment scenarios, it may be desirable to take a PW
operationally down if there is a mismatch of the Stack operationally down if there is a mismatch of the Stack
Capability between the PEs. In other deployment scenarios, an Capability between the PEs. In other deployment scenarios, an
operator may wish the IP version supported by both PEs to fall- operator may wish the IP version supported by both PEs to fall-
back to IPv4 if one of the PEs does not support IPv6. The back to IPv4 if one of the PEs does not support IPv6. The
skipping to change at page 29, line 27 skipping to change at page 29, line 21
Protocol (IPCP)", RFC 1332. Protocol (IPCP)", RFC 1332.
[RFC5072] D. Haskin, "IP Version 6 over PPP", RFC 5072. [RFC5072] D. Haskin, "IP Version 6 over PPP", RFC 5072.
[RFC925] J.Postel, "Multi-LAN Address Resolution", RFC [RFC925] J.Postel, "Multi-LAN Address Resolution", RFC
925. 925.
[RFC1256] S.Deering, "ICMP Router Discovery Messages", RFC [RFC1256] S.Deering, "ICMP Router Discovery Messages", RFC
1256. 1256.
[RFC3232] Reynolds and Postel, "Assigned Numbers", RFC
3232.
[RFC5309] Shen and Zinin, "Point-to-point operation over [RFC5309] Shen and Zinin, "Point-to-point operation over
LAN in Link State Routing Protocols", RFC 5309. LAN in Link State Routing Protocols", RFC 5309.
[SPROXY] S.Krishnan et al., "Secure Proxy ND support for [SPROXY] S.Krishnan et al., "Secure Proxy ND support for
SEND", draft-ietf-csi-proxy-send-05.txt SEND", draft-ietf-csi-proxy-send-05.txt
11. Authors' Addresses 11. Authors' Addresses
This document is the combined effort of many who have This document is the combined effort of many who have
contributed, carefully reviewed and provided the technical contributed, carefully reviewed and provided the technical
 End of changes. 23 change blocks. 
108 lines changed or deleted 96 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/