One document matched: draft-lee-softwire-6rd-udp-00.txt
Softwire Working Group Y. Lee
Internet-Draft Comcast
Intended status: Informational October 18, 2009
Expires: April 21, 2010
UDP Encapsulation of 6rd
draft-lee-softwire-6rd-udp-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 21, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Lee Expires April 21, 2010 [Page 1]
Internet-Draft 6RD Over UDP October 2009
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This memo specifies the UDP encapsulation to IPv6 Rapid Deployment
(6rd) protocol [I-D.ietf-softwire-ipv6-6rd] which enables hosts
behind unmodified Home Gateway device to access 6rd service.
Requirements 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].
Lee Expires April 21, 2010 [Page 2]
Internet-Draft 6RD Over UDP October 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. 6rd Host . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Home Gateway . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. 6rd Prefix . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. 6rd Border Router . . . . . . . . . . . . . . . . . . . . 6
3.5. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 6
3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6.1. Host Model . . . . . . . . . . . . . . . . . . . . . . 7
3.6.2. Server Model . . . . . . . . . . . . . . . . . . . . . 8
4. 6rd Prefix UDP Encapsulation . . . . . . . . . . . . . . . . . 9
4.1. UDP-Encapsulated 6rd Header . . . . . . . . . . . . . . . 9
5. 6rd Border Router Discovery . . . . . . . . . . . . . . . . . 10
5.1. Manual Discovery . . . . . . . . . . . . . . . . . . . . . 10
5.2. Automatic Discovery . . . . . . . . . . . . . . . . . . . 10
6. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Comparison to the Classic 6rd . . . . . . . . . . . . . . . . 10
7.1. Outside Initiated Traffic . . . . . . . . . . . . . . . . 11
7.2. Stateless vs. Stateful 6rd Border Router . . . . . . . . . 11
7.3. 6rd Prefix . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Comparison to Softwire Hub-and-Spoke and Teredo . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Lee Expires April 21, 2010 [Page 3]
Internet-Draft 6RD Over UDP October 2009
1. Introduction
6rd protocol [I-D.ietf-softwire-ipv6-6rd] enables service providers
to rapidly deploy IPv6 over IPv4 network. In [I-D.despres-6rd], it
describes the 6rd architecture to enable a service provider to deploy
IPv6 connectivity on an IPv4 network for 1.5 million residential
customers. The architecture involves two major components: (1) the
6rd relays (6rd Border Router) in the ISP network and (2) 6rd CPE
(6rd CE) in the customer premise.
The 6rd CE in the customer home is a NAT [RFC3022] device which
shares a single Subscribe IPv4 address [I-D.ietf-softwire-ipv6-6rd]
to multiple internal IPv4 hosts. Note that the subscriber IPv4
address can be either public or private. If private address is used,
the ISP will provide NAT function in the provider network. Details
is described in [I-D.despres-6rd] Section 4. The 6rd CE is also an
IPv6 router which advertises an IPv6 prefix (6rd Prefix) to the
internal IPv6 hosts. The 6rd Prefix consists of two part: the 6rd SP
Prefix and the Subscriber IPv4 address. The 6rd CE learns the 6rd SP
Prefix from DHCP [I-D.ietf-softwire-ipv6-6rd] and appends the
Subscriber IPv4 address to form the 6rd Prefix. Then, the 6rd CE
advertises the 6rd Prefix to the customer's home network via Router
Advertisement [RFC4861].
This architecture fits well to those ISPs who manage the customers'
Home Gateways (HGW). When the ISP is ready to deploy the 6rd, a new
firmware which contains the 6rd CE implementation will be pushed to
the managed HGW. For the ISPs who don't manage the customers' HWGs,
they can't upgrade the customer's HWGs to support 6rd. This memo
specific a UDP encapsulation to encapsulate 6rd over UDP which
enables ISP to deploy 6rd to hosts behind unmodified HWG. There are
two scenarios in which the ISP can use this specification.
1. First deployment scenario is the O/S in the host implements this
specification. When the host sends an IPv6 datagram, it first
encapsulates the IPv6 datagram in an IPv4 header following the
procedure defined in [I-D.despres-6rd]. Then, it encapsulates
the IPv4 datagram with a standard UDP header [RFC0768] Details of
the UDP encapsulation is described in Section 4.
2. Second deployment scenario is a dedicated server implements this
specification. The server is connected to the unmodified HGW's
LAN interface. Once the server establishes IPv4 connectivity, it
will initiate the 6rd discovery procedure and construct the 6rd
Prefix. Finally, it advertises the 6rd Prefix via Router
Advertisement to the HGW LAN so that IPv6 datagram will use the
server as a gateway to establish IPv6 sessions. This enables the
IPv6 hosts connecting to the HGW's LAN to enjoy 6rd service
Lee Expires April 21, 2010 [Page 4]
Internet-Draft 6RD Over UDP October 2009
without additional configuration.
2. Terminology
This documents users terms defined in [I-D.ietf-softwire-ipv6-6rd].
In addition, we defines the following new terms:
o HGW: is referred to the edge device installed in customer home.
It typically provides NAT function to the home equipments. The
HGW in this context is unaware of 6rd.
o 6rd BR-Id: is referred to the identifier embedded in the 6rd SP
Prefix. This field is ranged from 8-bit to 16-bit appears right
after the 6rd SP Prefix. Each 6rd BR is assigned a unique 6rd
BR-ID.
o 6rd SP-BR Prefix: is formed by concatenating 6rd SP prefix and 6rd
BR-Id. The 6rd host uses the 6rd SP-BR and the Subscriber IPv4
Address to form the 6rd Prefix.
o Internal IPv4 address: is referred to the private IPv4 address
assigned by the HGW to the host. This address is a [RFC1918]
address.
3. Overview
3.1. 6rd Host
Before the host can use 6rd, it needs to discover three pieces of
information: the 6rd SP-BR Prefix, the Subscriber IPv4 address, and
the 6rd BR IPv4 address. The host concatenates the 6rd SP-BR Prefix
and the Subscriber IPv4 address to form the 6rd Prefix. When the 6rd
host wants to initiate an IPv6 session to an outside IPv6 host, the
first encapsulates is to encapsulate the IPv6 datagram with an IPv4
header. The IPv4 header source address will be the internal IPv4
address assigned by the HGW. The destination address will be the 6rd
BR's IPv4 address. The second encapsulate is to encapsulate the IPv4
datagram in a UDP header. The UDP source port is any available UDP
port; the destination port is an IANA defined port.
The host implemented this specification is provisioned with the IPv4
address of the 6rd BR. Section 5 contains more discussion of the 6rd
BR discovery process.
Lee Expires April 21, 2010 [Page 5]
Internet-Draft 6RD Over UDP October 2009
3.2. Home Gateway
The HGW in this specification is a typical HGW found in retailed
stores. In the WAN side, it connects to the ISP and runs DHCP
client. The ISP offers an IPv4 address, a default gateway, and list
of DNS servers to the HGW. In the LAN side, it runs DHCP server and
offers [RFC1918] address to the hosts on the LAN. The HGW provides
standard NAT [RFC3022] functions to allow multiple hosts to share a
single Subscriber IPv4 address. When a host connects to the HGW, the
host requests the Internal IPv4 address and the Internal IPv4 Gateway
via DHCP. The HGW is not aware of the 6rd service.
3.3. 6rd Prefix
In order to construct the 6rd Prefix, the host must discover the 6rd
SP-BR Prefix and the Subscriber IPv4 address assigned to the HGW.
More discussion of discovering 6rd SP-BR Prefix can be found in
Section 5. How to discover the Subscriber IPv4 Address is out of
scope of the document. Hosts implemented this specification may
support the 6rd Delegated Prefix procedure defined in
[I-D.ietf-softwire-ipv6-6rd].
3.4. 6rd Border Router
The 6rd BR implemented this specification is assigned a 6rd BR-Id.
Each 6rd BR has a unique BR-Id. The 6rd BR in this specification is
stateful. This is a new requirement in contrast to the stateless 6rd
deployment with the 6rd CE. The reason for this stateful requirement
is when the 6rd BR de-capsulates the IPv4 header, the NAT-ed UDP
Source Port is lost. This information is needed to encapsulate the
returned datagram for the session to the HGW.
3.5. Procedure
When the 6rd host wants to send an IPv6 datagram to an IPv6
destination, it puts the 6rd Prefix in the source IPv6 address field.
Then it encapsulates the IPv6 datagram with an IPv4 header. The IPv4
header contains the 6rd BR in the destination address field and the
Internal IPv4 address in the source address field. Then the host
encapsulates the IPv4 datagram with a UDP header. The source port
can be any available port and the destination port is the well-known
port assigned by IANA.
When the HWG receives the first UDP datagram, it will NAT the source
port and source IPv4 address to create a NAT binding in its table.
Then, the HWG forwards the IPv4 UDP datagram to the 6rd BR. This
specification contains no new requirement to the HWG.
Lee Expires April 21, 2010 [Page 6]
Internet-Draft 6RD Over UDP October 2009
When the 6rd BR receives the UDP datagram, it will de-capsulate the
UDP header and IPv4 header. It will use the information in the IPv4
UDP header, the IPv6 TCP/UDP header, and the IPv6 header to create a
binding in its table. Then, the 6rd BR will forward the IPv6
datagram to the outside IPv6 destination.
3.6. Examples
3.6.1. Host Model
This example explains how the Host Model works. Both 6rd Host A and
6rd Host B learn the 6rd SP-BR prefix. They also learn the
Subscriber IPv4 address by some external mechanism. Host A and Host
B create the 6rd Prefix by concatenating 6rd SP-BR prefix and the
Subscriber IPv4 address.
3.6.1.1. Outbound Flow
When Host A initiates a session in IPv6, it will first encapsulate
the IPv6 datagram in an IPv4 header where the source address is the
Internal IPv4 address and the destination address it he 6rd BR IPv4
address. Then, Host A will add a UDP header to the datagram where
the source port can be any available port and the destination port is
the well-known port defined by IANA. When the HWG receives the first
UDP datagram, it performs classic NAT function on the UDP datagram
and forwards the NAT-ed UDP datagram to the 6rd BR.
For each new UDP session, the 6rd BR creates a binding. The binding
contains: IPv4 UDP source port, IPv6 source address, and IPv6
destination IPv6 TCP/UDP source port, and IPv6 TCP/UDP destination
port. Note that the 6rd is required to remember the sessions from
the HWG in order to use the correct IPv4 UDP port to encapsulate the
returned datagrams.
3.6.1.2. Inbound Flow
When the 6rd BR receives an IPv6 datagram, it checks the IPv4 source
address. If the source address belongs to one of its own, it checks
its binding table to see any match of the TCP/UDP destination port in
the IPv6 transport header. If a match is found, the 6rd BR will use
the IPv4 UDP port stored in the table and encapsulate the IPv6
datagram to UDP and IPv4 and forward the datagram to the Subscriber
IPv4 Address of the HWG. When the HWG receives the datagram, the HGW
replaces the destination port and destination IP address with the
information stored in the NAT table, and forward the datagram to the
6rd host.
Lee Expires April 21, 2010 [Page 7]
Internet-Draft 6RD Over UDP October 2009
| IPv6
| Global Internet
+-----+
| | 6rd Border Router
+-----+
|
+----------------------+
| |
| ISP IPv4 Network |
| |
| |
+----------------------+
| Subscriber IPv4
+-----+
| | Unmodified HGW
+-----+
| Internal IPv4
_________
| |
+===+ +===+
6rd Host A | | | | 6rd Host B
+===+ +===+
Figure 1
3.6.2. Server Model
This example is very similar to the Host Model. Instead of the host
implementing this specification, only the server device is required
to implement this specification. The server will use the same
mechanism described in the Host Model to construct the 6rd Prefix.
When the server is ready to provide the 6rd service, it will announce
the 6rd Prefix in the Router Advertisement. Client A and Client B
will receive the 6rd Prefix and auto-config the IPv6 interface using
the 6rd Prefix.
Lee Expires April 21, 2010 [Page 8]
Internet-Draft 6RD Over UDP October 2009
| IPv6
| Global Internet
+-----+
| | 6rd Border Router
+-----+
|
+----------------------+
| |
| ISP IPv4 Network |
| |
| |
+----------------------+
|
+-----+
| | Unmodified HGW
+-----+
|
____________________________________
| -- 6rd --> | |
| Prefix | |
+===+ +---+ +---+
| s | | c | | c |
+===+ +---+ +---+
server client A client B
Figure 2
4. 6rd Prefix UDP Encapsulation
4.1. UDP-Encapsulated 6rd Header
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6rd Datagram |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lee Expires April 21, 2010 [Page 9]
Internet-Draft 6RD Over UDP October 2009
Where
o the Source Port is any available port.
o the Destination Port must be the well-known port assigned by IANA.
o this specification does not introduce new requirement to the IPv4
UDP Length and Checksum.
5. 6rd Border Router Discovery
In the classic 6rd framework, the 6rd CE connects directly to the
ISP. The ISP uses DHCP to pass the 6rd SP Prefix and the 6rd BR
address to the CPE CE. In this specification, the 6rd host is not
directly connected to the ISP. Between the ISP and the 6rd host,
there is a HWG which is unaware of 6rd. The ISP can't use DHCP to
pass the necessary information to the 6rd hosts. In this
specification, we suggest two discovery mechanisms.
5.1. Manual Discovery
The ISP gives the customers the 6rd SP Prefix and 6rd BR information.
If the customers want to start the 6rd service, they must enter the
information manually. This method is only feasible in very small
scale deployment and not recommended for any large scale deployment.
5.2. Automatic Discovery
The ISP uses RADIUS [RFC2865] or DIAMETER [RFC3588] to distribute the
6rd SP-BR Prefix and 6rd BR IPv4 address information. When the
customer starts the 6rd service, he/she must authenticate him/herself
to the ISP. Upon a successful authentication, he/she will be given
the 6rd SP-BR Prefix and 6rd BR address through either RADIUS or
DIAMETER response.
6. MTU
Similar to other tunnel encapsulation, this specification reduces the
effect MTU size. The encapsulation overhead is 20-byte for IPv4
header and 8-byte for UDP. The host and 6rd BR must account for this
overhead.
7. Comparison to the Classic 6rd
This specification is considered more restrictive than the classic
Lee Expires April 21, 2010 [Page 10]
Internet-Draft 6RD Over UDP October 2009
6rd. There are three major areas:
7.1. Outside Initiated Traffic
In the classic 6rd model, 6rd CE is the IPv6 router of its managed
prefix. Outside initiated IPv6 traffic to the inside host will be
routed to the 6rd CE. After de-capsulating the IPv4 header, the 6rd
CE will forward the IPv6 datagrams to the host based upon the IPv6
destination address in the IPv6 header. This allows outside host to
initiate IPv6 session to the inside host.
In the UDP encapsulation mode, the IPv4 HGW is unaware of the IPv6
session. It will drop the UDP encapsulated datagram if there is no
existing session in the NAT table associated to incoming datagram.
This will prevent the outside host from initiating IPv6 session to
the inside host.
7.2. Stateless vs. Stateful 6rd Border Router
In the classic 6rd architecture, the 6rd BRs are stateless. All 6rd
BRs announces the same set of 6rd Prefixes. For both egress and
ingress sessions, routers can pick any 6rd BR to forward the traffic.
In fact, the communication path between the 6rd CE and outside host
can be asymmetric. As such, the 6rd CE could use 6rd BR1 for
forwarding path and the destination network could use 6rd BR2 for
returning path.
In the UDP encapsulation mode, the 6rd BRs are stateful. The reason
is when the 6rd BR de-capsulates the IPv4 header, the NAT-ed UDP
Source Port information is lost. This information is needed to
encapsulate the datagrams for the ingress session back to the HGW.
Thus, when the 6rd BR de-capsulates the IPv4 header, it will remember
the UDP Source Port and create a binding table for the session. This
requirement mandates the communication path between the 6rd host and
6rd BR must be symmetric. For example: If the 6rd host chose 6rd BR1
for forwarding path, the return path must also use the 6rd BR1.
7.3. 6rd Prefix
In the classic 6rd architecture, the 6rd BR announces the 6rd SP
Prefix to the public Internet. The outside host can pick any 6rd BR
to communicate to the IPv6 hosts behind the 6rd CE.
In the UDP encapsulation mode, the session between the 6rd host and
outside host must use the same 6rd BR. So the 6rd BR must announce a
more specific 6rd Prefix than the 6rd SP Prefix so that the outside
host will choose the correct 6rd BR when it responds to the inside
6rd host. Hence, each 6rd BR is given an 6rd BR-ID. The 6rd BR will
Lee Expires April 21, 2010 [Page 11]
Internet-Draft 6RD Over UDP October 2009
form the 6rd SP-BR Prefix by concatenating the 6rd SP prefix and the
BR-ID. During 6rd host bootstrapping, the 6rd host will be given
this specific prefix. The 6rd host will use it to construct the 6rd
prefix by combining the 6rd SP-BR prefix and the Subscriber IPv4
address.
8. Comparison to Softwire Hub-and-Spoke and Teredo
Softwire Hub-and-Spoke [RFC5571] and Teredo [RFC4380] are two
protocols that provide IPv6 connectivity to hosts behind typical HGW.
Softwire Hub-and-Spoke uses L2TPv2 over UDP [RFC2661] for the tunnel
protocol; Teredo defines its own tunneling protocol for UDP
encapsulation. This specification provides similar functionality.
The upside for this specification is that it does not require control
channel between the 6rd host and 6rd BR. The downside is UDP
encapsulation does not allow outside host to initiate session to the
6rd host. Besides, this specification require external bootstrapping
process to pass provisioning information to the 6rd host.
This specification can support both classic 6rd and UDP encapsulation
of 6rd in the 6rd BR. In a deployment scenario where customers have
mixed 6rd CE and typical HGW, this specification potentially saves
operation cost by deploying only one type of network equipments.
9. IANA Considerations
This specification requests IANA to assign a UDP port for the 6rd UDP
encapsulation.
10. Security Considerations
TBD
11. Acknowledgements
TBD
12. References
12.1. Normative References
[I-D.despres-6rd]
Despres, R., "IPv6 Rapid Deployment on IPv4
Lee Expires April 21, 2010 [Page 12]
Internet-Draft 6RD Over UDP October 2009
infrastructures (6rd)", draft-despres-6rd-03 (work in
progress), April 2009.
[I-D.ietf-softwire-ipv6-6rd]
Townsley, M. and O. Troan, "IPv6 via IPv4 Service Provider
Networks", draft-ietf-softwire-ipv6-6rd-00 (work in
progress), August 2009.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, B.,
Toutain, L., and J. Tremblay, "Softwire Hub and Spoke
Deployment Framework with Layer Two Tunneling Protocol
Version 2 (L2TPv2)", RFC 5571, June 2009.
12.2. Informative References
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
Lee Expires April 21, 2010 [Page 13]
Internet-Draft 6RD Over UDP October 2009
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
Author's Address
Yiu L. Lee
Comcast
Email: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
Lee Expires April 21, 2010 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 03:13:09 |