draft-ietf-6man-lineid-01.txt   draft-ietf-6man-lineid-02.txt 
6man Working Group S. Krishnan 6man Working Group S. Krishnan
Internet-Draft A. Kavanagh Internet-Draft A. Kavanagh
Intended status: Standards Track B. Varga Intended status: Standards Track B. Varga
Expires: September 15, 2011 Ericsson Expires: May 3, 2012 Ericsson
S. Ooghe S. Ooghe
Alcatel-Lucent Alcatel-Lucent
E. Nordmark E. Nordmark
Cisco Cisco
March 14, 2011 October 31, 2011
The Line Identification Destination Option The Line Identification Destination Option
draft-ietf-6man-lineid-01 draft-ietf-6man-lineid-02
Abstract Abstract
In Ethernet based aggregation networks, several subscriber premises In Ethernet based aggregation networks, several subscriber premises
may be logically connected to the same interface of an edge router. may be logically connected to the same interface of an edge router.
This document proposes a method for the edge router to identify the This document proposes a method for the edge router to identify the
subscriber premises using the contents of the received Router subscriber premises using the contents of the received Router
Solicitation messages. The applicability is limited to broadband Solicitation messages. The applicability is limited to broadband
network deployment scenarios where multiple user ports are mapped to network deployment scenarios where multiple user ports are mapped to
the same virtual interface on the Edge Router. the same virtual interface on the Edge Router.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 15, 2011. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions used in this document . . . . . . . . . . . . 5 1.2. Conventions used in this document . . . . . . . . . . . . 5
2. Issues with identifying the subscriber in an N:1 VLAN model . 6 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Issues with identifying the subscriber in an N:1 VLAN model . 6
4. Basic operation . . . . . . . . . . . . . . . . . . . . . . . 6 4. Basic operation . . . . . . . . . . . . . . . . . . . . . . . 7
5. Access Node Behavior . . . . . . . . . . . . . . . . . . . . . 6 5. Access Node Behavior . . . . . . . . . . . . . . . . . . . . . 7
5.1. On receiving a Router Solicitation from the end-device . . 6 5.1. On receiving a Router Solicitation from the end-device . . 7
5.2. On receiving a Router Advertisement from the Edge 5.2. On receiving a Router Advertisement from the Edge
Router . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Router . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2.1. Identifying tunneled Router Advertisements . . . . . . 7 5.2.1. Identifying tunneled Router Advertisements . . . . . . 8
5.3. On detecting a subscriber circuit coming up . . . . . . . 7 5.3. On detecting a subscriber circuit coming up . . . . . . . 8
6. Edge Router Behavior . . . . . . . . . . . . . . . . . . . . . 8 5.4. On detecting Edge Router failure . . . . . . . . . . . . . 8
5.5. RS Retransmission algorithm . . . . . . . . . . . . . . . 9
6. Edge Router Behavior . . . . . . . . . . . . . . . . . . . . . 9
6.1. On receiving a Tunneled Router Solicitation from the 6.1. On receiving a Tunneled Router Solicitation from the
Access Node . . . . . . . . . . . . . . . . . . . . . . . 8 Access Node . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. On sending a Router Advertisement towards the 6.2. On sending a Router Advertisement towards the
end-device . . . . . . . . . . . . . . . . . . . . . . . . 8 end-device . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Sending periodic unsolicited Router Advertisements 6.3. Sending periodic unsolicited Router Advertisements
towards the end-device . . . . . . . . . . . . . . . . . . 9 towards the end-device . . . . . . . . . . . . . . . . . . 10
7. Line Identification Destination Option (LIO) . . . . . . . . . 9 7. Line Identification Destination Option (LIO) . . . . . . . . . 10
8. Interactions with Secure Neighbor Discovery . . . . . . . . . 10 8. Garbage collection of unused prefixes . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. Interactions with Secure Neighbor Discovery . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. Normative References . . . . . . . . . . . . . . . . . . . . . 11 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 13. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Digital Subscriber Line (DSL) is a widely deployed access technology Digital Subscriber Line (DSL) is a widely deployed access technology
for Broadband Access for Next Generation Networks. While for Broadband Access for Next Generation Networks. While
traditionally DSL access networks were Point-to-Point Protocol (PPP) traditionally DSL access networks were Point-to-Point Protocol (PPP)
[RFC1661] based some networks are migrating from the traditional PPP [RFC1661] based some networks are migrating from the traditional PPP
access model into a pure IP-based Ethernet aggregated access access model into a pure IP-based Ethernet aggregated access
environment. Architectural and topological models of an Ethernet environment. Architectural and topological models of an Ethernet
aggregation network in context of DSL aggregation are described in aggregation network in context of DSL aggregation are described in
skipping to change at page 6, line 5 skipping to change at page 6, line 5
document. When a Layer 2 RG is used, the document. When a Layer 2 RG is used, the
host behind the RG is considered to be an host behind the RG is considered to be an
end-device in the context of this document. end-device in the context of this document.
1.2. Conventions used in this document 1.2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Issues with identifying the subscriber in an N:1 VLAN model 2. Applicability Statement
The line identification destination option is intended to be used
only for the N:1 VLAN deployment model. For the other VLAN
deployment models line identification can be achieved differently.
When DHCP is used for IPv6 address assignment it has the side-effect
of including reliability initiated by the end-device (the end-device
retransmits DHCP messages until it receives a response), as well as a
way to detect when the end-device is not active for an extended
period of time (the end-device would not renew its DHCP lease). IPv6
Stateless address autoconfiguration was not designed to satisfy such
requirements. While this protocol improves the the robustness of
relying on Router Solicitations in lieu of DHCP, this results on some
limitations specified below.
The mechanism described in this document deals with the loss of
subscriber-originated Router Solicitations by initiating RSs at the
Access Node, which improves the robustness over solely relying on the
end-device's few initial retransmissions of RSs. But the AN
retransmissions imply that some information that was obtained by the
network from subscriber-originated RSs may no longer be available.
e.g. Since there is no L2 frame received from the subscriber in case
of an RS sent by an AN, the L2 address information of the host cannot
be determined. One piece of L2 address information currently used in
Broadband networks is the MAC address. For this reason, the solution
described in this document is NOT RECOMMENDED for networks that
require the MAC address of the endpoint for identification.
There is no indication when a subscriber is no longer active. Thus
this protocol can not be used to automatically reclaim resources,
such as prefixes, that are associated with an active subscriber. See
Section 8. Thus this protocol is NOT RECOMMENDED for networks that
require automatic notification when a subscriber is no longer active.
This mechanism by itself provides no protection against the loss of
RS induced state in access routers that would lead to loss of IPv6
connectivity for hosts. Given that regular IPv6 hosts do not have RS
retransmission behavior that would allow automatic recovery from such
a failure, this mechanism is considered experimental and NOT
RECOMMENDED for general deployments.
3. Issues with identifying the subscriber in an N:1 VLAN model
In a DSL or GPON based fixed Broadband Network, IPv6 end-devices are In a DSL or GPON based fixed Broadband Network, IPv6 end-devices are
connected to an Access Node (AN). These end-devices today will connected to an Access Node (AN). These end-devices today will
typically send a Router Solicitation Message to the Edge Router, to typically send a Router Solicitation Message to the Edge Router, to
which the Edge Router responds with a Router Advertisement message. which the Edge Router responds with a Router Advertisement message.
The Router Advertisement typically contains a prefix that the end- The Router Advertisement typically contains a prefix that the end-
devices will use to automatically configure an IPv6 Address. Upon devices will use to automatically configure an IPv6 Address. Upon
sending the Router Solicitation message the node connecting the end- sending the Router Solicitation message the node connecting the end-
device on the access circuit, typically an Access Node (AN), would device on the access circuit, typically an Access Node (AN), would
forward the RS to the Edge Router upstream over a switched network. forward the RS to the Edge Router upstream over a switched network.
skipping to change at page 6, line 28 skipping to change at page 7, line 22
router (e.g. on the same VLAN). However, the edge router requires router (e.g. on the same VLAN). However, the edge router requires
some information to identify the end-device on the circuit the end- some information to identify the end-device on the circuit the end-
device is connected on. To accomplish this, the AN needs to add line device is connected on. To accomplish this, the AN needs to add line
identification information to the Router Solicitation message and identification information to the Router Solicitation message and
forward this to the Edge Router. This is analogous to the case where forward this to the Edge Router. This is analogous to the case where
DHCP is being used, and the line identification information is DHCP is being used, and the line identification information is
inserted by a DHCP relay agent. This document proposes a method for inserted by a DHCP relay agent. This document proposes a method for
the edge router to identify the subscriber premises using the the edge router to identify the subscriber premises using the
contents of the received Router Solicitation messages. contents of the received Router Solicitation messages.
3. Applicability
The line identification destination option is intended to be used
only for the N:1 VLAN deployment model. For the other VLAN
deployment models line identification can be achieved differently.
4. Basic operation 4. Basic operation
This document recommends tunneling Neighbor discovery packets inside This document recommends tunneling Neighbor discovery packets inside
another IPv6 packet that uses a destination option to convey line another IPv6 packet that uses a destination option to convey line
identification information. The Neighbor discovery packets are left identification information. The Neighbor discovery packets are left
unmodified inside the encapsulating IPv6 packet. In particular, the unmodified inside the encapsulating IPv6 packet. In particular, the
Hop Limit field of the ND message is not decremented when the packet Hop Limit field of the ND message is not decremented when the packet
is being tunneled. This is because ND messages whose Hop Limit is is being tunneled. This is because ND messages whose Hop Limit is
not 255 will be discarded by the receiver of such messages. not 255 will be discarded by the receiver of such messages.
skipping to change at page 8, line 4 skipping to change at page 8, line 40
device. To ensure that the end-device will receive an RA, the AN device. To ensure that the end-device will receive an RA, the AN
needs to trigger the sending of periodic RAs on the edge router. For needs to trigger the sending of periodic RAs on the edge router. For
this purpose, the AN needs to inform the edge router that a this purpose, the AN needs to inform the edge router that a
subscriber circuit has come up. When the access node detects that a subscriber circuit has come up. When the access node detects that a
subscriber circuit has come up, it MUST create a Router Solicitation subscriber circuit has come up, it MUST create a Router Solicitation
message as described in Section 6.3.7 of [RFC4861]. It MUST use the message as described in Section 6.3.7 of [RFC4861]. It MUST use the
unspecified address as the source address of this RS. It MUST then unspecified address as the source address of this RS. It MUST then
tunnel this RS towards the edge router as described in Section 5.1. tunnel this RS towards the edge router as described in Section 5.1.
In case there are connectivity issues between the AN and the edge In case there are connectivity issues between the AN and the edge
router, the RSes initiated by the AN can be lost. The AN MAY router, the RSs initiated by the AN can be lost. The AN SHOULD
continue retransmitting the Router Solicitations for a given LIO continue retransmitting the Router Solicitations following the
until it receives an RA for that specific LIO. algorithm described in Section 5.5 for a given LIO until it receives
an RA for that specific LIO.
Alternately, the AN can send this notification about the subscriber 5.4. On detecting Edge Router failure
circuit coming up using a out-of-band mechanism with acknowledgements
like ANCP, if such mechanism is available. When the edge router reboots and loses state or is replaced by a new
edge router, the AN will detect it using connectivity check
mechanisms that are already in place in Broadband networks (e.g.
BFD). When such edge router failure is detected, the AN needs to
start transmitting RSs for each of its subscriber circuits that are
up as described in Section 5.3.
5.5. RS Retransmission algorithm
The AN SHOULD use the exponential backoff algorithm for retransmits
that is described in Section 14 of [RFC3315] in order to continuously
retransmit the Router Solicitations for a given LIO until a response
is received for that specific LIO. The AN SHOULD use the following
variables as input to the retransmission algorithm:
IRT 1 Second
MRT 30 Seconds
MRC 0
MRD 0
6. Edge Router Behavior 6. Edge Router Behavior
6.1. On receiving a Tunneled Router Solicitation from the Access Node 6.1. On receiving a Tunneled Router Solicitation from the Access Node
When the edge router receives a tunneled Router Solicitation When the edge router receives a tunneled Router Solicitation
forwarded by the access node, it needs to check if there is an LIO forwarded by the access node, it needs to check if there is an LIO
destination option present in the outer datagram. The edge router destination option present in the outer datagram. The edge router
can use the contents of the line identification field to lookup the can use the contents of the line identification field to lookup the
addressing information and policy that need to be applied to the line addressing information and policy that need to be applied to the line
skipping to change at page 9, line 32 skipping to change at page 10, line 38
option that can be included in IPv6 datagrams that tunnel Router option that can be included in IPv6 datagrams that tunnel Router
Solicitation and Router Advertisement messages. Multiple Line Solicitation and Router Advertisement messages. Multiple Line
Identification destination options MUST NOT be present in the same Identification destination options MUST NOT be present in the same
IPv6 datagram. The LIO has an alignment requirement of (none). IPv6 datagram. The LIO has an alignment requirement of (none).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | | Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Line Identification... | LineIDLen | Line Identification...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Line Identification Destination Option Layout Figure 3: Line Identification Destination Option Layout
Option Type Option Type
8-bit identifier of the type of option. The option identifier 8-bit identifier of the type of option. The option identifier
for the line identification option will be allocated by the IANA. for the line identification option will be allocated by the IANA.
Option Length Option Length
skipping to change at page 10, line 27 skipping to change at page 11, line 27
Length of the Line Identification field in number of octets. Length of the Line Identification field in number of octets.
Line Identification Line Identification
Variable length data inserted by the Access Node describing the Variable length data inserted by the Access Node describing the
subscriber agent circuit identifier corresponding to the logical subscriber agent circuit identifier corresponding to the logical
access loop port of the Access Node from which the RS was access loop port of the Access Node from which the RS was
initiated. initiated.
8. Interactions with Secure Neighbor Discovery 8. Garbage collection of unused prefixes
Following the mechanism described in this document, the Broadband
network associates a prefix to a subscriber line based on the LIO.
Even when the subscriber line goes down temporarily, this prefix
stays allocated to that specific subscriber line. i.e. The prefix is
not returned to the unused pool. When a subscriber line no longer
needs a prefix, the prefix can be reclaimed by manual action
dissociating the prefix from the LIO in the backend systems.
9. Interactions with Secure Neighbor Discovery
Since the SEND [RFC3971] protected RS/RA packets are not modified in Since the SEND [RFC3971] protected RS/RA packets are not modified in
anyway by the mechanism described in this document, there are no anyway by the mechanism described in this document, there are no
issues with SEND verification. issues with SEND verification.
9. Acknowledgements 10. Acknowledgements
The authors would like to thank Margaret Wasserman, Mark Townsley, The authors would like to thank Margaret Wasserman, Mark Townsley,
David Miles, John Kaippallimalil, Eric Levy-Abegnoli, Thomas Narten, David Miles, John Kaippallimalil, Eric Levy-Abegnoli, Thomas Narten,
Olaf Bonness, Thomas Haag, Wojciech Dec, Brian Haberman, Ole Troan, Olaf Bonness, Thomas Haag, Wojciech Dec, Brian Haberman, Ole Troan,
Hemant Singh, Jari Arkko and Joel Halpern for reviewing this document Hemant Singh, Jari Arkko, Joel Halpern and Bob Hinden for reviewing
and suggesting changes. this document and suggesting changes.
10. Security Considerations 11. Security Considerations
The line identification information inserted by the access node or The line identification information inserted by the access node or
the edge router is not protected. This means that this option may be the edge router is not protected. This means that this option may be
modified, inserted, or deleted without being detected. In order to modified, inserted, or deleted without being detected. In order to
ensure validity of the contents of the line identification field, the ensure validity of the contents of the line identification field, the
network between the access node and the edge router needs to be network between the access node and the edge router needs to be
trusted. trusted.
11. IANA Considerations 12. IANA Considerations
This document defines a new IPv6 destination option for carrying line This document defines a new IPv6 destination option for carrying line
identification. IANA is requested to assign a new destination option identification. IANA is requested to assign a new destination option
type in the Destination Options registry maintained at type in the Destination Options registry maintained at
http://www.iana.org/assignments/ipv6-parameters http://www.iana.org/assignments/ipv6-parameters
<TBA1> Line Identification Option [RFCXXXX] <TBA1> Line Identification Option [RFCXXXX]
The act bits for this option need to be 10 and the chg bit needs to The act bits for this option need to be 10 and the chg bit needs to
skipping to change at page 11, line 27 skipping to change at page 12, line 37
This document also requires the allocation of a well-known link-local This document also requires the allocation of a well-known link-local
scope multicast address from the IPv6 Multicast Address Space scope multicast address from the IPv6 Multicast Address Space
Registry located at Registry located at
http://www.iana.org/assignments/ipv6-multicast-addresses/ http://www.iana.org/assignments/ipv6-multicast-addresses/
ipv6-multicast-addresses.xml ipv6-multicast-addresses.xml
<TBA2> All BBF Access Nodes [RFCXXXX] <TBA2> All BBF Access Nodes [RFCXXXX]
12. Normative References 13. Normative References
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994. RFC 1661, July 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998. IPv6 Specification", RFC 2473, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[TR101] Broadband Forum, "Migration to Ethernet-based DSL [TR101] Broadband Forum, "Migration to Ethernet-based DSL
aggregation", <http://www.broadband-forum.org/technical/ aggregation", <http://www.broadband-forum.org/technical/
download/TR-101.pdf>. download/TR-101.pdf>.
skipping to change at page 13, line 4 skipping to change at page 14, line 17
Email: balazs.a.varga@ericsson.com Email: balazs.a.varga@ericsson.com
Sven Ooghe Sven Ooghe
Alcatel-Lucent Alcatel-Lucent
Copernicuslaan 50 Copernicuslaan 50
2018 Antwerp, 2018 Antwerp,
Belgium Belgium
Phone: Phone:
Email: sven.ooghe@alcatel-lucent.com Email: sven.ooghe@alcatel-lucent.com
Erik Nordmark Erik Nordmark
Cisco Cisco
510 McCarthy Blvd.
Milpitas, CA, 95035
USA
Email: nordmark@acm.org Phone: +1 408 527 6625
Email: nordmark@cisco.com
 End of changes. 24 change blocks. 
44 lines changed or deleted 120 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/