draft-ietf-lwig-guidance-00.txt   draft-ietf-lwig-guidance-01.txt 
LWIG Working Group C. Bormann, Ed. LWIG Working Group C. Bormann, Ed.
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Intended status: Informational June 05, 2012 Intended status: Informational July 16, 2012
Expires: December 7, 2012 Expires: January 17, 2013
Guidance for Light-Weight Implementations of the Internet Protocol Suite Guidance for Light-Weight Implementations of the Internet Protocol Suite
draft-ietf-lwig-guidance-00 draft-ietf-lwig-guidance-01
Abstract Abstract
Implementation of Internet protocols on small devices benefits from Implementation of Internet protocols on small devices benefits from
light-weight implementation techniques, which are often not light-weight implementation techniques, which are often not
documented in an accessible way. documented in an accessible way.
This document provides a first outline of and some initial content This document provides a first outline of and some initial content
for the Light-Weight Implementation Guidance document planned by the for the Light-Weight Implementation Guidance document planned by the
IETF working group LWIG. IETF working group LWIG.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 December 7, 2012. This Internet-Draft will expire on January 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
2.3. Implementation Styles . . . . . . . . . . . . . . . . . . 8 2.3. Implementation Styles . . . . . . . . . . . . . . . . . . 8
2.4. Roles of nodes . . . . . . . . . . . . . . . . . . . . . . 9 2.4. Roles of nodes . . . . . . . . . . . . . . . . . . . . . . 9
2.5. Overview over the document . . . . . . . . . . . . . . . . 9 2.5. Overview over the document . . . . . . . . . . . . . . . . 9
3. Data Plane Protocols . . . . . . . . . . . . . . . . . . . . . 10 3. Data Plane Protocols . . . . . . . . . . . . . . . . . . . . . 10
3.1. Link Adaptation Layer . . . . . . . . . . . . . . . . . . 10 3.1. Link Adaptation Layer . . . . . . . . . . . . . . . . . . 10
3.1.1. Fragmentation in a 6LoWPAN Route-Over Configuration . 10 3.1.1. Fragmentation in a 6LoWPAN Route-Over Configuration . 10
3.1.1.1. Implementation Considerations for 3.1.1.1. Implementation Considerations for
Not-So-Constrained Nodes . . . . . . . . . . . . . 11 Not-So-Constrained Nodes . . . . . . . . . . . . . 11
3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 11 3.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 11
3.4. Application Layer . . . . . . . . . . . . . . . . . . . . 12 3.3.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1.1. Absolutely required TCP behaviors for proper
functioning and interoperability . . . . . . . . . 12
3.3.1.2. Strongly encouraged, but non-essential,
behaviors of TCP . . . . . . . . . . . . . . . . . 13
3.3.1.3. Experimental extensions that are not yet
standard practices . . . . . . . . . . . . . . . . 15
3.3.1.4. Others . . . . . . . . . . . . . . . . . . . . . . 15
3.4. Application Layer . . . . . . . . . . . . . . . . . . . . 15
3.4.1. General considerations about Application 3.4.1. General considerations about Application
Programming Interfaces (APIs) . . . . . . . . . . . . 12 Programming Interfaces (APIs) . . . . . . . . . . . . 15
3.4.2. Constrained Application Protocol (CoAP) . . . . . . . 12 3.4.2. Constrained Application Protocol (CoAP) . . . . . . . 16
3.4.2.1. Message Layer Processing . . . . . . . . . . . . . 13 3.4.2.1. Message Layer Processing . . . . . . . . . . . . . 17
3.4.2.2. Message Parsing . . . . . . . . . . . . . . . . . 14 3.4.2.2. Message Parsing . . . . . . . . . . . . . . . . . 18
3.4.2.3. Storing Used Message IDs . . . . . . . . . . . . . 15 3.4.2.3. Storing Used Message IDs . . . . . . . . . . . . . 19
3.4.3. (Other Application Protocols...) . . . . . . . . . . . 18 3.4.3. (Other Application Protocols...) . . . . . . . . . . . 22
4. Control Plane Protocols . . . . . . . . . . . . . . . . . . . 19 4. Control Plane Protocols . . . . . . . . . . . . . . . . . . . 23
4.1. Link Layer Support . . . . . . . . . . . . . . . . . . . . 19 4.1. Link Layer Support . . . . . . . . . . . . . . . . . . . . 23
4.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 19 4.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 23
4.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4. Host Configuration and Lookup Services . . . . . . . . . . 19 4.4. Host Configuration and Lookup Services . . . . . . . . . . 23
4.5. Network Management . . . . . . . . . . . . . . . . . . . . 19 4.5. Network Management . . . . . . . . . . . . . . . . . . . . 23
4.5.1. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.5.1. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5.1.1. Background . . . . . . . . . . . . . . . . . . . . 20 4.5.1.1. Background . . . . . . . . . . . . . . . . . . . . 24
4.5.1.2. Revisiting SNMP implementation for resource 4.5.1.2. Revisiting SNMP implementation for resource
constrained devices . . . . . . . . . . . . . . . 20 constrained devices . . . . . . . . . . . . . . . 24
4.5.1.3. Proposed approach for building an memory 4.5.1.3. Proposed approach for building an memory
efficient SNMP agent . . . . . . . . . . . . . . . 21 efficient SNMP agent . . . . . . . . . . . . . . . 25
4.5.1.4. Example . . . . . . . . . . . . . . . . . . . . . 21 4.5.1.4. Example . . . . . . . . . . . . . . . . . . . . . 25
4.5.1.5. Further improvements . . . . . . . . . . . . . . . 24 4.5.1.5. Further improvements . . . . . . . . . . . . . . . 28
4.5.1.6. Conclusion . . . . . . . . . . . . . . . . . . . . 24 4.5.1.6. Conclusion . . . . . . . . . . . . . . . . . . . . 28
5. Security protocols . . . . . . . . . . . . . . . . . . . . . . 25 5. Security protocols . . . . . . . . . . . . . . . . . . . . . . 29
5.1. Cryptography for Constrained Devices . . . . . . . . . . . 25 5.1. Cryptography for Constrained Devices . . . . . . . . . . . 29
5.2. Transport Layer Security . . . . . . . . . . . . . . . . . 25 5.2. Transport Layer Security . . . . . . . . . . . . . . . . . 29
5.3. Network Layer Security . . . . . . . . . . . . . . . . . . 25 5.3. Network Layer Security . . . . . . . . . . . . . . . . . . 29
5.4. Network Access Control . . . . . . . . . . . . . . . . . . 25 5.4. Network Access Control . . . . . . . . . . . . . . . . . . 29
5.4.1. PANA . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.4.1. PANA . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4.1.1. PANA AVPs . . . . . . . . . . . . . . . . . . . . 25 5.4.1.1. PANA AVPs . . . . . . . . . . . . . . . . . . . . 29
5.4.1.2. PANA Phases . . . . . . . . . . . . . . . . . . . 26 5.4.1.2. PANA Phases . . . . . . . . . . . . . . . . . . . 30
5.4.1.3. PANA session state parameters . . . . . . . . . . 28 5.4.1.3. PANA session state parameters . . . . . . . . . . 32
6. Wire-Visible Constraints . . . . . . . . . . . . . . . . . . . 31 6. Wire-Visible Constraints . . . . . . . . . . . . . . . . . . . 35
7. Wire-Invisible Constraints . . . . . . . . . . . . . . . . . . 32 7. Wire-Invisible Constraints . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . 35 10.1. Contributors . . . . . . . . . . . . . . . . . . . . . . . 39
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.1. Normative References . . . . . . . . . . . . . . . . . . . 36 11.1. Normative References . . . . . . . . . . . . . . . . . . . 40
11.2. Informative References . . . . . . . . . . . . . . . . . . 36 11.2. Informative References . . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
Today's Internet is experienced by users as a set of applications, Today's Internet is experienced by users as a set of applications,
such as email, instant messaging, and social networks. There are such as email, instant messaging, and social networks. There are
substantial differences in performance between the various end substantial differences in performance between the various end
devices with these applications, but in general end devices devices with these applications, but in general end devices
participating in the Internet today are considered to have relatively participating in the Internet today are considered to have relatively
high performance. high performance.
skipping to change at page 12, line 5 skipping to change at page 12, line 5
Both TCP and UDP employ 16-bit one's-complement checksums to protect Both TCP and UDP employ 16-bit one's-complement checksums to protect
against transmission errors. A number of RFCs discuss efficient against transmission errors. A number of RFCs discuss efficient
implementation techniques for computing and updating Internet implementation techniques for computing and updating Internet
Checksums [RFC1071] [RFC1141] [RFC1624]. (Updating the Internet Checksums [RFC1071] [RFC1141] [RFC1624]. (Updating the Internet
Checksum, as opposed to computing it from scratch, may be of interest Checksum, as opposed to computing it from scratch, may be of interest
where a pre-computed packet is provided, e.g., in Flash ROM, and a where a pre-computed packet is provided, e.g., in Flash ROM, and a
copy is made in RAM and updated with some current values, or when the copy is made in RAM and updated with some current values, or when the
actual transmitted packet is composed from pre-defined parts in ROM actual transmitted packet is composed from pre-defined parts in ROM
and new parts in RAM.) and new parts in RAM.)
3.3.1. TCP
Ed. Note:
The following outline of a section is an attempt to provide
substructure for a future discussion of TCP-related issues based on
the TCP Roadmap, [RFC4614]. The indented text, as well as the RFC
citations, are copied (and redacted) from there; this certainly needs
to be refined in a future version. (Some additional adaptation of
the material may also be required as RFC 2581 was since obsoleted by
RFC 5681, and RFC 3782 was obsoleted by RFC 6582.)
Author: Yuanchen Ma
In [RFC4614], the TCP related RFCs are summarized. Some RFCs
describe absolutely required TCP behaviors for proper functioning and
interoperability. Further RFCs describe strongly encouraged, but
non-essential, behaviors. There are also experimental extensions
that are not yet standard practices, but that potentially could be in
the future.
In this subsection, the influence of resource constrained nodes on
TCP implementations are summarized according to the lists of
[RFC4614].
3.3.1.1. Absolutely required TCP behaviors for proper functioning and
interoperability
RFC 793 S: "Transmission Control Protocol", STD 7 (September 1981)
In RFC793, the TCP state machine and event processing, and TCP's
semantics for data transmission, reliability, flow control,
multiplexing, and acknowledgment. For this part, the constraint of
memory will limit the multiplexing capability of TCP. /_text needed
for RFC793_/
RFC 1122 S: "Requirements for Internet Hosts - Communication Layers"
(October 1989)
RFC 2460 S: "Internet Protocol, Version 6 (IPv6) Specification
(December 1998)
RFC 2873 S: "TCP Processing of the IPv4 Precedence Field" (June 2000)
This document [RFC2873] removes from the TCP specification all
processing of the precedence bits of the TOS byte of the IP
header.
These three RFCs mandate the support for IPv6 and TOS in IP header,
which are a must for resource constrained node to implement.
RFC 2581 S: "TCP Congestion Control" (April 1999)
Although RFC 793 did not contain any congestion control
mechanisms, today congestion control is a required component of
TCP implementations. This document [RFC2581] defines the current
versions of Van Jacobson's congestion avoidance and control
mechanisms for TCP, based on his 1988 SIGCOMM paper [Jac88]. RFC
2001 was a conceptual precursor that was obsoleted by RFC 2581.
A number of behaviors that together constitute what the community
refers to as "Reno TCP" are described in RFC 2581.
RFC 1122 mandates the implementation of a congestion control
mechanism, and RFC 2581 details the currently accepted mechanism.
RFC 2581 differs slightly from the other documents listed in this
section, as it does not affect the ability of two TCP endpoints to
communicate; however, congestion control remains a critical
component of any widely deployed TCP implementation and is
required for the avoidance of congestion collapse and to ensure
fairness among competing flows.
RFC 2988 S: "Computing TCP's Retransmission Timer" (November 2000)
Abstract: "This document defines the standard algorithm that
Transmission Control Protocol (TCP) senders are required to use to
compute and manage their retransmission timer.
3.3.1.2. Strongly encouraged, but non-essential, behaviors of TCP
RFC 1323 S: "TCP Extensions for High Performance" (May 1992)
This document [RFC1323] defines TCP extensions for window scaling,
timestamps, and protection against wrapped sequence numbers, for
efficient and safe operation over paths with large bandwidth-delay
products.
RFC 2675 S: "IPv6 Jumbograms" (August 1999)
IPv6 supports longer datagrams than were allowed in IPv4.
RFC 3168 S: "The Addition of Explicit Congestion Notification (ECN)
to IP" (September 2001)
3.3.1.2.1. Congestion Control and Loss Recovery Extensions
RFC 3042 S: "Enhancing TCP's Loss Recovery Using Limited Transmit"
(January 2001)
Abstract: "This document proposes Limited Transmit, a new
Transmission Control Protocol (TCP) mechanism that can be used to
more effectively recover lost segments when a connection's
congestion window is small
RFC 3390 S: "Increasing TCP's Initial Window" (October 2002)
This document [RFC3390] updates RFC 2581 to permit an initial TCP
window of three or four segments during the slow-start phase,
depending on the segment size.
RFC 3782 S: "The NewReno Modification to TCP's Fast Recovery
Algorithm" (April 2004)
This document [RFC3782] specifies a modification to the standard
Reno fast recovery algorithm, whereby a TCP sender can use partial
acknowledgments to make inferences determining the next segment to
send in situations where SACK would be helpful but isn't
available.
3.3.1.2.2. SACK-Based Loss Recovery and Congestion Control
RFC 2018 S: "TCP Selective Acknowledgment Options" (October 1996)
This document [RFC2018] defines the basic selective acknowledgment
(SACK) mechanism for TCP.
RFC 2883 S: "An Extension to the Selective Acknowledgement (SACK)
Option for TCP" (July 2000)
This document [RFC2883] extends RFC 2018 to cover the case of
acknowledging duplicate segments.
RFC 3517 S: "A Conservative Selective Acknowledgment (SACK)-based
Loss Recovery Algorithm for TCP" (April 2003)
3.3.1.2.3. Dealing with Forged Segments
RFC 1948 I: "Defending Against Sequence Number Attacks" (May 1996)
RFC 2385 S: "Protection of BGP Sessions via the TCP MD5 Signature
Option" (August 1998)
3.3.1.3. Experimental extensions that are not yet standard practices
The experimental extensions are not mature yet. The contents need to
be validated to be safe and logical behavior. It is not recommended
for the resource constrained node to implement.
3.3.1.4. Others
RFC 2923 I: "TCP Problems with Path MTU Discovery" (September 2000)
From abstract: "This memo catalogs several known Transmission
Control Protocol (TCP) implementation problems dealing with Path
Maximum Transmission Unit Discovery (PMTUD), including the long-
standing black hole problem, stretch acknowlegements (ACKs) due to
confusion between Maximum Segment Size (MSS) and segment size, and
MSS advertisement based on PMTU." [RFC2923]
3.4. Application Layer 3.4. Application Layer
3.4.1. General considerations about Application Programming Interfaces 3.4.1. General considerations about Application Programming Interfaces
(APIs) (APIs)
Author: Carl Williams Author: Carl Williams
Constrained devices are not necessarily in a position to use APIs Constrained devices are not necessarily in a position to use APIs
that would be considered "standard" for less constrained environments that would be considered "standard" for less constrained environments
(e.g., Berkeley sockets or those defined by POSIX). (e.g., Berkeley sockets or those defined by POSIX).
skipping to change at page 35, line 21 skipping to change at page 39, line 21
to improved text. to improved text.
10.1. Contributors 10.1. Contributors
The RFC guidelines no longer allow RFCs to be published with a large The RFC guidelines no longer allow RFCs to be published with a large
number of authors. As there are many authors that have contributed number of authors. As there are many authors that have contributed
to the sections of this document, their names are listed in the to the sections of this document, their names are listed in the
individual section headings as well as alphabetically listed with individual section headings as well as alphabetically listed with
their affiliations below. their affiliations below.
+--------------+----------------------+-----------------------------+ +-------------+-----------------------+-----------------------------+
| Name | Affiliation | Contact | | Name | Affiliation | Contact |
+--------------+----------------------+-----------------------------+ +-------------+-----------------------+-----------------------------+
| Brinda M C | Indian Institute of | brinda@ece.iisc.ernet.in | | Brinda M C | Indian Institute of | brinda@ece.iisc.ernet.in |
| | Science | | | | Science | |
| | | | | | | |
| Carl | MCSR Labs | carlw@mcsr-labs.org | | Carl | MCSR Labs | carlw@mcsr-labs.org |
| Williams | | | | Williams | | |
| | | | | | | |
| Carsten | Universitaet Bremen | cabo@tzi.org | | Carsten | Universitaet Bremen | cabo@tzi.org |
| Bormann | TZI | | | Bormann | TZI | |
| | | | | | | |
| Esko Dijk | Philips Research | esko.dijk@philips.com | | Esko Dijk | Philips Research | esko.dijk@philips.com |
| | | | | | | |
| Mitsuru | Toshiba | mitsuru.kanda@toshiba.co.jp | | Mitsuru | Toshiba | mitsuru.kanda@toshiba.co.jp |
| Kanda | | | | Kanda | | |
| | | | | | | |
| Olaf | Universitaet Bremen | bergmann@tzi.org | | Olaf | Universitaet Bremen | bergmann@tzi.org |
| Bergmann | TZI | | | Bergmann | TZI | |
| | | | | | | |
| ... | ... | | | Yuanchen Ma | Hitachi (China) R&D | ycma@hitachi.cn |
+--------------+----------------------+-----------------------------+ | | Corporation | |
| | | |
| ... | ... | |
+-------------+-----------------------+-----------------------------+
11. References 11. References
11.1. Normative References 11.1. Normative References
[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.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
skipping to change at page 36, line 27 skipping to change at page 40, line 27
[I-D.arkko-core-sleepy-sensors] [I-D.arkko-core-sleepy-sensors]
Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O.
Novo, "Implementing Tiny COAP Sensors", Novo, "Implementing Tiny COAP Sensors",
draft-arkko-core-sleepy-sensors-01 (work in progress), draft-arkko-core-sleepy-sensors-01 (work in progress),
July 2011. July 2011.
[I-D.ietf-core-coap] [I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank, Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)", "Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-09 (work in progress), March 2012. draft-ietf-core-coap-10 (work in progress), June 2012.
[I-D.kivinen-ipsecme-ikev2-minimal] [I-D.kivinen-ipsecme-ikev2-minimal]
Kivinen, T., "Minimal IKEv2", Kivinen, T., "Minimal IKEv2",
draft-kivinen-ipsecme-ikev2-minimal-00 (work in progress), draft-kivinen-ipsecme-ikev2-minimal-00 (work in progress),
February 2011. February 2011.
[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer,
"Computing the Internet checksum", RFC 1071, "Computing the Internet checksum", RFC 1071,
September 1988. September 1988.
skipping to change at page 36, line 52 skipping to change at page 40, line 52
Incremental Update", RFC 1624, May 1994. Incremental Update", RFC 1624, May 1994.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap
for Transmission Control Protocol (TCP) Specification
Documents", RFC 4614, September 2006.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008. Access (PANA)", RFC 5191, May 2008.
[WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded [WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded
Internet", ISBN 9780470747995, 2009. Internet", ISBN 9780470747995, 2009.
Author's Address Author's Address
Carsten Bormann (editor) Carsten Bormann (editor)
Universitaet Bremen TZI Universitaet Bremen TZI
 End of changes. 12 change blocks. 
67 lines changed or deleted 240 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/