draft-ietf-v6ops-64share-08.txt | draft-ietf-v6ops-64share-09.txt | |||
---|---|---|---|---|
V6OPS Working Group C. Byrne | V6OPS Working Group C. Byrne | |||
Internet-Draft T-Mobile USA | Internet-Draft T-Mobile USA | |||
Intended Status: Informational D. Drown | Intended Status: Informational D. Drown | |||
Expires: January 15, 2014 A. Vizdal | Expires: April 9, 2014 A. Vizdal | |||
Deutsche Telekom AG | Deutsche Telekom AG | |||
July 14, 2013 | October 6, 2013 | |||
Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a LAN link | Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a LAN link | |||
draft-ietf-v6ops-64share-08 | draft-ietf-v6ops-64share-09 | |||
Abstract | Abstract | |||
This document describes two methods for extending an IPv6 /64 prefix | This document describes requirements for extending an IPv6 /64 prefix | |||
from a User Equipment 3GPP radio interface to a LAN link. | from a User Equipment 3GPP radio interface to a LAN link as well as | |||
two implementation examples. | ||||
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 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 November 18, 2013. | This Internet-Draft will expire on April 6, 2014. | |||
Copyright and License Notice | Copyright and License Notice | |||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2013 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 respect | carefully, as they describe your rights and restrictions with respect | |||
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.2 Special Language . . . . . . . . . . . . . . . . . . . . . . 3 | ||||
2. The Challenge of Providing IPv6 Addresses to a LAN link via a | 2. The Challenge of Providing IPv6 Addresses to a LAN link via a | |||
3GPP UE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 3GPP UE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Methods for Extending the 3GPP Interface /64 IPv6 Prefix to a | 3. Requirements for Extending the 3GPP Interface /64 IPv6 Prefix | |||
LAN link . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | to a LAN link . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.1 General Behavior for All Scenarios . . . . . . . . . . . . . 4 | 4. Example Methods for Extending the 3GPP Interface /64 IPv6 | |||
3.2 Scenario 1: Global Address Only Assigned to LAN link . . . . 4 | Prefix to a LAN link . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.3 Scenario 2: A Single Global Address Assigned to 3GPP Radio | 4.1 General Behavior for All Example Scenarios . . . . . . . . . 4 | |||
and LAN link . . . . . . . . . . . . . . . . . . . . . . . . 5 | 4.2 Example Scenario 1: Global Address Only Assigned to LAN | |||
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 | link . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 | 4.3 Example Scenario 2: A Single Global Address Assigned to | |||
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 | 3GPP Radio and LAN link . . . . . . . . . . . . . . . . . . 6 | |||
7. Informative References . . . . . . . . . . . . . . . . . . . . 7 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 | ||||
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 | ||||
8. Informative References . . . . . . . . . . . . . . . . . . . . 7 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 | ||||
1. Introduction | 1. Introduction | |||
3GPP mobile cellular networks such as GSM, UMTS, and LTE have | 3GPP mobile cellular networks such as GSM, UMTS, and LTE have | |||
architectural support for IPv6 [RFC6459], but only 3GPP Release-10 | architectural support for IPv6 [RFC6459] , but only 3GPP Release-10 | |||
and onwards of the 3GPP specification supports DHCPv6 Prefix | and onwards of the 3GPP specification supports DHCPv6 Prefix | |||
Delegation [RFC3633] for delegating IPv6 prefixes to a single LAN | Delegation [RFC3633] for delegating IPv6 prefixes to a single LAN | |||
link. To facilitate the use of IPv6 in a LAN prior to the deployment | link. To facilitate the use of IPv6 in a LAN prior to the deployment | |||
of DHCPv6 Prefix Delegation in 3GPP networks and in User Equipment | of DHCPv6 Prefix Delegation in 3GPP networks and in User Equipment | |||
(UE), this document describes how the 3GPP UE radio interface | (UE), this document describes requirements and provides examples on | |||
assigned global /64 prefix may be extended from the 3GPP radio | how the 3GPP UE radio interface assigned global /64 prefix may be | |||
interface to a LAN link. This is achieved by receiving the Router | extended from the 3GPP radio interface to a LAN link. | |||
Advertisement (RA) [RFC4861] announced globally unique /64 IPv6 | ||||
prefix from the 3GPP radio interface and then advertising the same | ||||
IPv6 prefix to the LAN link with RA. For all of the cases in the | ||||
scope of this document, the UE may be any device that functions as an | ||||
IPv6 router between the 3GPP network and a LAN. | ||||
This document describes two methods for achieving IPv6 prefix | This can be achieved by receiving the Router Advertisement (RA) | |||
extension from a 3GPP radio interface to a LAN link including: | [RFC4861] announced globally unique /64 IPv6 prefix from the 3GPP | |||
radio interface and then advertising the same IPv6 prefix to the LAN | ||||
link with RA. For all of the cases in the scope of this document, | ||||
the UE may be any device that functions as an IPv6 router between the | ||||
3GPP network and a LAN. | ||||
This document describes requirements for achieving IPv6 prefix | ||||
extension from a 3GPP radio interface to a LAN link including two | ||||
practical implementation examples: | ||||
1) The 3GPP UE only has a global scope address on the LAN link | 1) The 3GPP UE only has a global scope address on the LAN link | |||
2) The 3GPP UE maintains the same consistent 128 bit global scope | 2) The 3GPP UE maintains the same consistent 128 bit global scope | |||
IPv6 anycast address [RFC4291] on the 3GPP radio interface and the | IPv6 anycast address [RFC4291] on the 3GPP radio interface and the | |||
LAN link. The LAN link is configured as a /64 and the 3GPP radio | LAN link. The LAN link is configured as a /64 and the 3GPP radio | |||
interface is configured as a /128. | interface is configured as a /128. | |||
Section 3 describes the characteristics of each of the two | Section 3 describes the characteristics of each of the two example | |||
approaches. | approaches. | |||
1.2 Special Language | ||||
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 [RFC2119]. | ||||
NOTE WELL: This document is not a standard, and conformance with | ||||
it is not required in order to claim conformance with IETF | ||||
standards for IPv6. | ||||
This document uses the normative keywords only for precision. | ||||
2. The Challenge of Providing IPv6 Addresses to a LAN link via a 3GPP UE | 2. The Challenge of Providing IPv6 Addresses to a LAN link via a 3GPP UE | |||
As described in [RFC6459], 3GPP networks assign a /64 global scope | As described in [RFC6459], 3GPP networks assign a /64 global scope | |||
prefix to each UE using RA. DHCPv6 Prefix Delegation is an optional | prefix to each UE using RA. DHCPv6 Prefix Delegation is an optional | |||
part of 3GPP Release-10 and is not covered by any earlier releases. | part of 3GPP Release-10 and is not covered by any earlier releases. | |||
Neighbor Discovery Proxy (ND Proxy) [RFC4389] functionality has been | Neighbor Discovery Proxy (ND Proxy) [RFC4389] functionality has been | |||
suggested as an option for extending the assigned /64 from the 3GPP | suggested as an option for extending the assigned /64 from the 3GPP | |||
radio interface to the LAN link, but ND Proxy is an experimental | radio interface to the LAN link, but ND Proxy is an experimental | |||
protocol and has some limitations with loop-avoidance. | protocol and has some limitations with loop-avoidance. | |||
DHCPv6 is the best way to delegate a prefix to a LAN link. The | DHCPv6 is the best way to delegate a prefix to a LAN link. The | |||
methods described in this document should only be applied when | methods described in this document should only be applied when | |||
deploying DHCPv6 Prefix Delegation is not achievable in the 3GPP | deploying DHCPv6 Prefix Delegation is not achievable in the 3GPP | |||
network and the UE. The methods described in this document are at | network and the UE. The methods described in this document are at | |||
various stages of implementation and deployment planning. The goal | various stages of implementation and deployment planning. The goal | |||
of this memo is to document the available methods which may be used | of this memo is to document the available methods which may be used | |||
prior to DHCPv6 deployment. | prior to DHCPv6 deployment. | |||
3. Methods for Extending the 3GPP Interface /64 IPv6 Prefix to a LAN | 3. Requirements for Extending the 3GPP Interface /64 IPv6 Prefix to a | |||
link | LAN link | |||
3.1 General Behavior for All Scenarios | R-1: The 3GPP network provided /64 prefix MUST be made available on | |||
the LAN link. | ||||
LAN attached devices shall be able to use the 3GPP network | ||||
assigned IPv6 prefix (e.g. using SLAAC [RFC4862]). | ||||
R-2: The UE MUST defend all its IPv6 addresses on the LAN link. | ||||
In case a LAN attached node will e.g. autoconfigure the same | ||||
global IPv6 address as used on the 3GPP interface, the UE must | ||||
fail the Duplicate Address Detection process run by the LAN node. | ||||
R-3: The LAN link configuration MUST be tightly coupled with the 3GPP | ||||
link state. | ||||
R-4: The UE MUST decrement the TTL when passing packets between IPv6 | ||||
links across the UE. | ||||
4. Example Methods for Extending the 3GPP Interface /64 IPv6 Prefix to a | ||||
LAN link | ||||
4.1 General Behavior for All Example Scenarios | ||||
As [RFC6459] describes, the 3GPP network assigned /64 is completely | As [RFC6459] describes, the 3GPP network assigned /64 is completely | |||
dedicated to the UE and the gateway does not consume any of the /64 | dedicated to the UE and the gateway does not consume any of the /64 | |||
addresses. The gateway routes the entire /64 to the UE and does not | addresses. The gateway routes the entire /64 to the UE and does not | |||
perform ND or Network Unreachability Detection (NUD) [RFC4861]. | perform ND or Network Unreachability Detection (NUD) [RFC4861]. | |||
Communication between the UE and the gateway is only done using link- | Communication between the UE and the gateway is only done using link- | |||
local addresses and the link is point-to-point. This allows for the | local addresses and the link is point-to-point. This allows for the | |||
UE to reliably manipulate the /64 from the 3GPP radio interface | UE to reliably manipulate the /64 from the 3GPP radio interface | |||
without negatively impacting the point-to-point 3GPP radio link | without negatively impacting the point-to-point 3GPP radio link | |||
interface. The LAN link RA configuration must be tightly coupled | interface. The LAN link RA configuration must be tightly coupled | |||
with the 3GPP link state. If the 3GPP link goes down or changes the | with the 3GPP link state. If the 3GPP link goes down or changes the | |||
IPv6 prefix, that state should be reflected in the LAN link IPv6 | IPv6 prefix, that state should be reflected in the LAN link IPv6 | |||
configuration. Just as in a standard IPv6 router, the packet TTL | configuration. Just as in a standard IPv6 router, the packet TTL | |||
will be decremented when passing packets between IPv6 links across | will be decremented when passing packets between IPv6 links across | |||
the UE. The UE is employing the weak host model. The RA function on | the UE. The UE is employing the weak host model [RFC1122]. The RA | |||
the UE is exclusively run on the LAN link. | function on the UE is exclusively run on the LAN link. | |||
The LAN link originated RA message carries a copy of the following | The LAN link originated RA message carries a copy of the following | |||
3GPP radio link received RA message option fields: | 3GPP radio link received RA message option fields: | |||
o MTU (if not provided by the 3GPP network, the UE will provide its | o MTU (if not provided by the 3GPP network, the UE will provide its | |||
3GPP link MTU size) | 3GPP link MTU size) | |||
o Prefix Information | o Prefix Information | |||
3.2 Scenario 1: Global Address Only Assigned to LAN link | 4.2 Example Scenario 1: Global Address Only Assigned to LAN link | |||
For this case, the UE receives the RA from the 3GPP network but does | For this case, the UE receives the RA from the 3GPP network but does | |||
not use a global address on the 3GPP interface. The 3GPP RA /64 | not use a global address on the 3GPP interface. The 3GPP RA /64 | |||
prefix information is used to configure NDP on the LAN and assigns | prefix information is used to configure NDP on the LAN and assigns | |||
itself an address on the LAN link. The LAN link uses RA to announce | itself an address on the LAN link. The LAN link uses RA to announce | |||
the prefix to the LAN. The UE LAN link interface defends its LAN | the prefix to the LAN. The UE LAN link interface defends its LAN | |||
IPv6 address with DAD. The UE shall not run Stateless Address | IPv6 address with DAD. The UE shall not run Stateless Address | |||
Autoconfiguration [RFC4862] to assign a global address on the 3GPP | Autoconfiguration [RFC4862] to assign a global address on the 3GPP | |||
radio interface while routing is enabled. | radio interface while routing is enabled. | |||
This method allows the UE to originate and terminate IPv6 | This method allows the UE to originate and terminate IPv6 | |||
communications as a host while acting as an IPv6 router. The | communications as a host while acting as an IPv6 router. The | |||
movement of the IPv6 prefix from the 3GPP radio interface to the LAN | movement of the IPv6 prefix from the 3GPP radio interface to the LAN | |||
link may result in long-lived data connections being terminated | link may result in long-lived data connections being terminated | |||
during the transition from a host-only mode to router-and-host mode. | during the transition from a host-only mode to router-and-host mode. | |||
Connections which are likely to be effected are ones that have been | Connections which are likely to be affected are ones that have been | |||
specifically bound to the 3GPP radio interface. This method is | specifically bound to the 3GPP radio interface. This method is | |||
appropriate if the UE or software on the UE cannot support multiple | appropriate if the UE or software on the UE cannot support multiple | |||
interfaces with the same anycast IPv6 address and the UE requires | interfaces with the same anycast IPv6 address and the UE requires | |||
global connectivity while acting as a router. | global connectivity while acting as a router. | |||
Below is the general procedure for this scenario: | Below is the general procedure for this scenario: | |||
1. The user activates router functionality for a LAN on the UE. | 1. The user activates router functionality for a LAN on the UE. | |||
2. The UE checks to make sure the 3GPP interface is active and has | 2. The UE checks to make sure the 3GPP interface is active and has | |||
skipping to change at page 5, line 37 | skipping to change at page 6, line 25 | |||
2001:db8:ac10:f002:1234:4567:0:9. | 2001:db8:ac10:f002:1234:4567:0:9. | |||
6. The UE, acting as a router running NDP on the LAN, will route | 6. The UE, acting as a router running NDP on the LAN, will route | |||
packets to and from the LAN. IPv6 packets passing between | packets to and from the LAN. IPv6 packets passing between | |||
interfaces will have the TTL decremented. | interfaces will have the TTL decremented. | |||
7. On the LAN link interface, there is no chance of address conflict | 7. On the LAN link interface, there is no chance of address conflict | |||
since the address is defended using DAD. The 3GPP radio | since the address is defended using DAD. The 3GPP radio | |||
interface only has a link-local address. | interface only has a link-local address. | |||
3.3 Scenario 2: A Single Global Address Assigned to 3GPP Radio and LAN | 4.3 Example Scenario 2: A Single Global Address Assigned to 3GPP Radio | |||
link | and LAN link | |||
In this method, the UE assigns itself one address from the 3GPP | In this method, the UE assigns itself one address from the 3GPP | |||
network RA announced /64. This one address is configured as anycast | network RA announced /64. This one address is configured as anycast | |||
[RFC4291] on both the 3GPP radio link as a /128 and on the LAN link | [RFC4291] on both the 3GPP radio link as a /128 and on the LAN link | |||
as a /64. This allows the UE to maintain long lived data connections | as a /64. This allows the UE to maintain long lived data connections | |||
since the 3GPP radio interface address does not change when the | since the 3GPP radio interface address does not change when the | |||
router function is activated. This method may cause complications | router function is activated. This method may cause complications | |||
for certain software that may not support multiple interfaces with | for certain software that may not support multiple interfaces with | |||
the same anycast IPv6 address or are sensitive to prefix length | the same anycast IPv6 address or are sensitive to prefix length | |||
changes. This method also creates complications for ensuring | changes. This method also creates complications for ensuring | |||
skipping to change at page 6, line 40 | skipping to change at page 7, line 29 | |||
has 2001:db8:ac10:f002:1234:4567:0:9/128. | has 2001:db8:ac10:f002:1234:4567:0:9/128. | |||
5. The UE directly processes all packets destined to itself at | 5. The UE directly processes all packets destined to itself at | |||
2001:db8:ac10:f002:1234:4567:0:9. | 2001:db8:ac10:f002:1234:4567:0:9. | |||
6. On the LAN interface, there is no chance of address conflict | 6. On the LAN interface, there is no chance of address conflict | |||
since the address is defended using DAD. The 3GPP radio | since the address is defended using DAD. The 3GPP radio | |||
interface only has a /128 and no other systems on the 3GPP radio | interface only has a /128 and no other systems on the 3GPP radio | |||
point-to-point link may use the global /64. | point-to-point link may use the global /64. | |||
4. Security Considerations | 5. Security Considerations | |||
tbd | Since the UE will be switched from an IPv6 host mode to an IPv6 | |||
router-and-host mode a basic IPv6 CPE security functions [RFC6092] | ||||
shall be considered. | ||||
5. IANA Considerations | 6. IANA Considerations | |||
This document does not require any action from IANA. | This document does not require any action from IANA. | |||
6. Acknowledgments | 7. Acknowledgments | |||
Many thanks for review and discussion from Dave Thaler, Sylvain | Many thanks for review and discussion from Dave Thaler, Sylvain | |||
Decremps, Mark Smith, Dmitry Anipko, Masanobu Kawashima, Teemu | Decremps, Mark Smith, Dmitry Anipko, Masanobu Kawashima, Teemu | |||
Savolainen, Mikael Abrahamsson, Eric Vyncke, Alexandru Petrescu, | Savolainen, Mikael Abrahamsson, Eric Vyncke, Alexandru Petrescu, | |||
Jouni Korhonen, Lorenzo Colitti, Julien Laganier and Owen DeLong. | Jouni Korhonen, Lorenzo Colitti, Julien Laganier, Owen DeLong and | |||
Holger Metschulat. | ||||
7. Informative References | 8. Informative References | |||
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery | [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - | |||
for IP version 6", RFC 1981, August 1996. | Communication Layers", STD 3, RFC 1122, October 1989. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | ||||
Requirement Levels", BCP 14, RFC 2119, March 1997. | ||||
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic | [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic | |||
Host Configuration Protocol (DHCP) version 6", RFC 3633, | Host Configuration Protocol (DHCP) version 6", RFC 3633, | |||
December 2003. | December 2003. | |||
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing | [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing | |||
Architecture", RFC 4291, February 2006. | Architecture", RFC 4291, February 2006. | |||
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery | [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery | |||
Proxies (ND Proxy)", RFC 4389, April 2006. | Proxies (ND Proxy)", RFC 4389, April 2006. | |||
skipping to change at page 7, line 35 | skipping to change at page 8, line 27 | |||
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, | "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, | |||
September 2007. | September 2007. | |||
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless | [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless | |||
Address Autoconfiguration", RFC 4862, September 2007. | Address Autoconfiguration", RFC 4862, September 2007. | |||
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy | [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy | |||
Extensions for Stateless Address Autoconfiguration in | Extensions for Stateless Address Autoconfiguration in | |||
IPv6", RFC 4941, September 2007. | IPv6", RFC 4941, September 2007. | |||
Authors' Addresses | [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security | |||
Capabilities in Customer Premises Equipment (CPE) for | ||||
Providing Residential IPv6 Internet Service", RFC 6092, | ||||
January 2011. | ||||
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, | ||||
T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation | ||||
Partnership Project (3GPP) Evolved Packet System (EPS)", | ||||
RFC 6459, January 2012. | ||||
Authors' Addresses | ||||
Cameron Byrne | Cameron Byrne | |||
T-Mobile USA | T-Mobile USA | |||
Bellevue, Washington, USA | Bellevue, Washington, USA | |||
EMail: Cameron.Byrne@T-Mobile.com | EMail: Cameron.Byrne@T-Mobile.com | |||
Dan Drown | Dan Drown | |||
Email: Dan@Drown.org | Email: Dan@Drown.org | |||
Ales Vizdal | Ales Vizdal | |||
End of changes. 26 change blocks. | ||||
46 lines changed or deleted | 105 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/ |