Home Networking Control Protocol
draft-ietf-homenet-hncp-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7788.
|
|
|---|---|---|---|
| Authors | Markus Stenberg , Steven Barth | ||
| Last updated | 2014-06-25 | ||
| Replaces | draft-stenberg-homenet-hncp | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 7788 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-homenet-hncp-01
Storage Maintenance (storm) WG Mallikarjun Chadalapaka
Internet Draft Microsoft
draft-ietf-storm-iscsi-cons-08.txt
Intended status: Proposed Standard Julian Satran
Expires: July 2013 Infinidat Ltd.
Obsoletes: RFC3720, RFC3980, RFC4850, RFC5048
Updates: RFC3721, RFC3723 Kalman Meth
IBM
David Black
EMC
iSCSI Protocol (Consolidated)
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
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
Chadalapaka et al. Expires July 15, 2013 [Page 1]
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 15, 2013.
Copyright Notice
Copyright (c) 2013 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
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
This document describes a transport protocol for SCSI that works
on top of TCP. The iSCSI protocol aims to be fully compliant with
the standardized SCSI Architecture Model (SAM-2). RFC 3720
defined the original iSCSI protocol. RFC 3721 discusses iSCSI
Naming examples and discovery techniques. Subsequently, RFC 3980
added an additional naming format to iSCSI protocol. RFC 4850
followed up by adding a new public extension key to iSCSI. RFC
5048 offered a number of clarifications and a few improvements and
corrections to the original iSCSI protocol.
This document obsoletes RFCs 3720, 3980, 4850 and 5048 by
consolidating them into a single document and making additional
updates to the consolidated specification. This document also
updates RFC 3721 and RFC 3723. The text in this document thus
supersedes the text in all the noted RFCs wherever there is a
difference in semantics.
Chadalapaka et al. Expires July 15, 2013 [Page 2]
iSCSI (Consolidated) 1/13/13
Note: This version of the draft does not yet incorporate planned
resolutions to some Last Call comments regarding Kerberos and
IPsec-related security considerations.
Chadalapaka et al. Expires July 15, 2013 [Page 3]
iSCSI (Consolidated) 1/13/13
1. Introduction.................................................... 15
2. Acronyms, Definitions and Document Summary...................... 16
2.1. Acronyms ...................................................16
2.2. Definitions ................................................18
2.3. Summary of Changes .........................................25
2.4. Conventions ................................................26
3. UML Conventions................................................. 27
3.1. UML Conventions Overview ...................................27
3.2. Multiplicity Notion ........................................27
3.3. Class Diagram Conventions ..................................28
3.4. Class Diagram Notation for Associations ....................29
3.5. Class Diagram Notation for Aggregations ....................30
3.6. Class Diagram Notation for Generalizations .................30
4. Overview........................................................ 32
4.1. SCSI Concepts ............................................... 32
4.2. iSCSI Concepts and Functional Overview ...................... 33
4.2.1. Layers and Sessions ..................................... 34
4.2.2. Ordering and iSCSI Numbering ............................ 35
4.2.2.1. Command Numbering and Acknowledging ................. 35
4.2.2.2. Response/Status Numbering and Acknowledging ......... 39
4.2.2.3. Response Ordering ................................... 40
4.2.2.3.1. Need for Response Ordering ...................... 40
4.2.2.3.2. Response Ordering Model Description ............. 40
4.2.2.3.3. iSCSI Semantics with the Interface Model ........ 41
4.2.2.3.4. Current List of Fenced Response Use Cases ....... 42
4.2.2.4. Data Sequencing ..................................... 43
4.2.3. iSCSI Task Management ................................... 44
4.2.3.1. Task Management Overview ............................ 44
4.2.3.2. Notion of Affected Tasks ............................ 44
4.2.3.3. Standard Multi-task Abort Semantics ................. 45
4.2.3.4. FastAbort Multi-task Abort Semantics ................ 46
4.2.3.5. Affected Tasks Shared across Standard and FastAbort
Sessions ..................................................... 48
Chadalapaka et al. Expires July 15, 2013 [Page 4]
iSCSI (Consolidated) 1/13/13
4.2.3.6. Rationale behind the FastAbort Semantics ............49
4.2.4. iSCSI Login .............................................51
4.2.5. iSCSI Full Feature Phase ................................52
4.2.5.1. Command Connection Allegiance .......................53
4.2.5.2. Data Transfer Overview ..............................54
4.2.5.3. Tags and Integrity Checks ...........................55
4.2.5.4. Task Management .....................................56
4.2.6. iSCSI Connection Termination ............................56
4.2.7. iSCSI Names .............................................57
4.2.7.1. iSCSI Name Properties ...............................58
4.2.7.2. iSCSI Name Encoding .................................60
4.2.7.3. iSCSI Name Structure ................................61
4.2.7.4. Type "iqn." (iSCSI Qualified Name) ..................62
4.2.7.5. Type "eui." (IEEE EUI-64 format) ....................64
4.2.7.6. Type "naa." - Network Address Authority .............64
4.2.8. Persistent State ........................................65
4.2.9. Message Synchronization and Steering ....................66
4.2.9.1. Sync/Steering and iSCSI PDU Length ..................67
4.3. iSCSI Session Types .........................................67
4.4. SCSI to iSCSI Concepts Mapping Model ........................68
4.4.1. iSCSI Architecture Model ................................69
4.4.2. SCSI Architecture Model .................................72
4.4.3. Consequences of the Model ...............................74
4.4.3.1. I_T Nexus State .....................................75
4.4.3.2. Reservations ........................................75
4.5. iSCSI UML Model .............................................76
4.6. Request/Response Summary ....................................79
4.6.1. Request/Response Types Carrying SCSI Payload ............79
4.6.1.1. SCSI-Command ........................................79
4.6.1.2. SCSI-Response .......................................80
4.6.1.3. Task Management Function Request ....................80
4.6.1.4. Task Management Function Response ...................81
4.6.1.5. SCSI Data-out and SCSI Data-in ......................81
4.6.1.6. Ready To Transfer (R2T) .............................82
4.6.2. Requests/Responses carrying SCSI and iSCSI Payload ......83
4.6.2.1. Asynchronous Message ................................83
Chadalapaka et al. Expires July 15, 2013 [Page 5]
iSCSI (Consolidated) 1/13/13
4.6.3. Requests/Responses Carrying iSCSI Only Payload ..........83
4.6.3.1. Text Request and Text Response ......................83
4.6.3.2. Login Request and Login Response ....................84
4.6.3.3. Logout Request and Response .........................85
4.6.3.4. SNACK Request .......................................85
4.6.3.5. Reject ..............................................85
4.6.3.6. NOP-Out Request and NOP-In Response .................86
5. SCSI Mode Parameters for iSCSI.................................. 87
6. Login and Full Feature Phase Negotiation........................ 88
6.1. Text Format ................................................. 89
6.2. Text Mode Negotiation ....................................... 93
6.2.1. List negotiations ....................................... 97
6.2.2. Simple-value Negotiations ............................... 98
6.3. Login Phase ................................................. 99
6.3.1. Login Phase Start ...................................... 102
6.3.2. iSCSI Security Negotiation ............................. 105
6.3.3. Operational Parameter Negotiation During the Login Phase 106
6.3.4. Connection Reinstatement ............................... 107
6.3.5. Session Reinstatement, Closure, and Timeout ............ 108
6.3.5.1. Loss of Nexus Notification .......................... 108
6.3.6. Session Continuation and Failure ....................... 109
6.4. Operational Parameter Negotiation Outside the Login Phase .. 109
7. iSCSI Error Handling and Recovery.............................. 111
7.1. Overview .................................................. 111
7.1.1. Background ............................................ 111
7.1.2. Goals ................................................. 111
7.1.3. Protocol Features and State Expectations .............. 112
7.1.4. Recovery Classes ...................................... 113
7.1.4.1. Recovery Within-command ........................... 114
7.1.4.2. Recovery Within-connection ........................ 115
7.1.4.3. Connection Recovery ............................... 116
7.1.4.4. Session Recovery .................................. 117
7.1.5. Error Recovery Hierarchy .............................. 117
7.2. Retry and Reassign in Recovery ............................ 119
Chadalapaka et al. Expires July 15, 2013 [Page 6]
iSCSI (Consolidated) 1/13/13
7.2.1. Usage of Retry ........................................ 119
7.2.2. Allegiance Reassignment ............................... 120
7.3. Usage Of Reject PDU in Recovery ........................... 121
7.4. Error Recovery Considerations for Discovery Sessions ...... 122
7.4.1. ErrorRecoveryLevel for Discovery Sessions ............. 122
7.4.2. Reinstatement Semantics for Discovery Sessions ........ 122
7.4.2.1. Unnamed Discovery Sessions ........................ 123
7.4.2.2. Named Discovery Session ........................... 124
7.4.3. Target PDUs During Discovery .......................... 124
7.5. Connection Timeout Management ............................. 124
7.5.1. Timeouts on Transport Exception Events ................ 125
7.5.2. Timeouts on Planned Decommissioning ................... 125
7.6. Implicit Termination of Tasks ............................. 125
7.7. Format Errors ............................................. 126
7.8. Digest Errors ............................................. 127
7.9. Sequence Errors ........................................... 129
7.10. Message Error Checking ................................... 129
7.11. SCSI Timeouts ............................................ 130
7.12. Negotiation Failures ..................................... 131
7.13. Protocol Errors .......................................... 131
7.14. Connection Failures ...................................... 132
7.15. Session Errors ........................................... 133
8. State Transitions.............................................. 134
8.1. Standard Connection State Diagrams ........................ 134
8.1.1. State Descriptions for Initiators and Targets ......... 134
8.1.2. State Transition Descriptions for Initiators and Targets 135
8.1.3. Standard Connection State Diagram for an Initiator ..... 139
8.1.4. Standard Connection State Diagram for a Target ......... 141
8.2. Connection Cleanup State Diagram for Initiators and Targets 143
8.2.1. State Descriptions for Initiators and Targets .......... 145
8.2.2. State Transition Descriptions for Initiators and Targets 146
8.3. Session State Diagrams ..................................... 148
8.3.1. Session State Diagram for an Initiator ................. 148
8.3.2. Session State Diagram for a Target ..................... 149
8.3.3. State Descriptions for Initiators and Targets .......... 150
Chadalapaka et al. Expires July 15, 2013 [Page 7]
iSCSI (Consolidated) 1/13/13
8.3.4. State Transition Descriptions for Initiators and Targets 151
9. Security Considerations........................................ 153
9.1. iSCSI Security Mechanisms .................................. 153
9.2. In-band Initiator-Target Authentication .................... 154
9.2.1. CHAP Considerations .................................... 155
9.2.2. SRP Considerations ..................................... 158
9.3. IPsec ...................................................... 158
9.3.1. Data Integrity and Authentication ...................... 159
9.3.2. Confidentiality ........................................ 160
9.3.3. Policy, Security Associations, and Cryptographic Key
Management .................................................... 161
9.4. Security Considerations for the X#NodeArchitecture Key ..... 162
9.5. SCSI Access Control Considerations ......................... 164
10. Notes to Implementers......................................... 165
10.1. Multiple Network Adapters ................................. 165
10.1.1. Conservative Reuse of ISIDs ........................... 165
10.1.2. iSCSI Name, ISID, and TPGT Use ........................ 166
10.2. Autosense and Auto Contingent Allegiance (ACA) ............ 168
10.3. iSCSI Timeouts ............................................ 168
10.4. Command Retry and Cleaning Old Command Instances .......... 169
10.5. Synch and Steering Layer and Performance .................. 170
10.6. Considerations for State-dependent Devices and Long-lasting
SCSI Operations ................................................. 170
10.6.1. Determining the Proper ErrorRecoveryLevel ............. 171
10.7. Multi-task Abort Implementation Considerations ............ 172
11. iSCSI PDU Formats............................................. 173
11.1. iSCSI PDU Length and Padding .............................. 173
11.2. PDU Template, Header, and Opcodes ......................... 173
11.2.1. Basic Header Segment (BHS) ............................ 174
11.2.1.1. I ................................................. 175
11.2.1.2. Opcode ............................................ 175
11.2.1.3. Final (F) bit ..................................... 177
11.2.1.4. Opcode-specific Fields ............................ 177
11.2.1.5. TotalAHSLength .................................... 177
Chadalapaka et al. Expires July 15, 2013 [Page 8]
iSCSI (Consolidated) 1/13/13
11.2.1.6. DataSegmentLength ................................. 177
11.2.1.7. LUN ............................................... 177
11.2.1.8. Initiator Task Tag ................................ 178
11.2.2. Additional Header Segment (AHS) ....................... 178
11.2.2.1. AHSType ........................................... 178
11.2.2.2. AHSLength ......................................... 179
11.2.2.3. Extended CDB AHS .................................. 179
11.2.2.4. Bidirectional Expected Read-Data Length AHS ....... 179
11.2.3. Header Digest and Data Digest ......................... 180
11.2.4. Data Segment .......................................... 180
11.3. SCSI Command .............................................. 180
11.3.1. Flags and Task Attributes (byte 1) .................... 181
11.3.2. CmdSN - Command Sequence Number ....................... 182
11.3.3. ExpStatSN ............................................. 183
11.3.4. Expected Data Transfer Length ......................... 183
11.3.5. CDB - SCSI Command Descriptor Block ................... 184
11.3.6. Data Segment - Command Data ........................... 184
11.4. SCSI Response ............................................. 184
11.4.1. Flags (byte 1) ........................................ 185
11.4.2. Status ................................................ 186
11.4.3. Response .............................................. 187
11.4.4. SNACK Tag ............................................. 188
11.4.5. Residual Count ........................................ 188
11.4.5.1. Field Semantics ................................... 188
11.4.5.2. Residuals Concepts Overview ....................... 189
11.4.5.3. SCSI REPORT LUNS and Residual Overflow ............ 189
11.4.6. Bidirectional Read Residual Count ..................... 191
11.4.7. Data Segment - Sense and Response Data Segment ........ 191
11.4.7.1. SenseLength ....................................... 192
11.4.7.2. Sense Data ........................................ 192
11.4.8. ExpDataSN ............................................. 193
11.4.9. StatSN - Status Sequence Number ....................... 193
11.4.10. ExpCmdSN - Next Expected CmdSN from this Initiator ... 194
11.4.11. MaxCmdSN - Maximum CmdSN from this Initiator ......... 194
11.5. Task Management Function Request .......................... 195
11.5.1. Function .............................................. 195
Chadalapaka et al. Expires July 15, 2013 [Page 9]
iSCSI (Consolidated) 1/13/13
11.5.2. TotalAHSLength and DataSegmentLength .................. 199
11.5.3. LUN ................................................... 199
11.5.4. Referenced Task Tag ................................... 199
11.5.5. RefCmdSN .............................................. 199
11.5.6. ExpDataSN ............................................. 200
11.6. Task Management Function Response ......................... 200
11.6.1. Response .............................................. 201
11.6.2. TotalAHSLength and DataSegmentLength .................. 203
11.7. SCSI Data-out & SCSI Data-in .............................. 203
11.7.1. F (Final) Bit ......................................... 206
11.7.2. A (Acknowledge) bit ................................... 206
11.7.3. Flags (byte 1) ........................................ 207
11.7.4. Target Transfer Tag and LUN ........................... 208
11.7.5. DataSN ................................................ 208
11.7.6. Buffer Offset ......................................... 208
11.7.7. DataSegmentLength ..................................... 209
11.8. Ready To Transfer (R2T) ................................... 210
11.8.1. TotalAHSLength and DataSegmentLength .................. 212
11.8.2. R2TSN ................................................. 212
11.8.3. StatSN ................................................ 212
11.8.4. Desired Data Transfer Length and Buffer Offset ........ 212
11.8.5. Target Transfer Tag ................................... 212
11.9. Asynchronous Message ...................................... 213
11.9.1. AsyncEvent ............................................ 214
11.9.2. AsyncVCode ............................................ 217
11.9.3. LUN ................................................... 217
11.9.4. Sense Data and iSCSI Event Data ....................... 217
11.9.4.1. SenseLength ....................................... 218
11.10. Text Request ............................................. 218
11.10.1. F (Final) Bit ........................................ 220
11.10.2. C (Continue) Bit ..................................... 220
11.10.3. Initiator Task Tag ................................... 220
11.10.4. Target Transfer Tag .................................. 220
11.10.5. Text ................................................. 221
11.11. Text Response ............................................ 222
11.11.1. F (Final) Bit ........................................ 223
Chadalapaka et al. Expires July 15, 2013 [Page 10]
iSCSI (Consolidated) 1/13/13
11.11.2. C (Continue) Bit ..................................... 224
11.11.3. Initiator Task Tag ................................... 224
11.11.4. Target Transfer Tag .................................. 224
11.11.5. StatSN ............................................... 225
11.11.6. Text Response Data ................................... 225
11.12. Login Request ............................................ 225
11.12.1. T (Transit) Bit ...................................... 226
11.12.2. C (Continue) Bit ..................................... 227
11.12.3. CSG and NSG .......................................... 227
11.12.4. Version .............................................. 227
11.12.4.1. Version-max ...................................... 227
11.12.4.2. Version-min ...................................... 228
11.12.5. ISID ................................................. 228
11.12.6. TSIH ................................................. 230
11.12.7. Connection ID - CID .................................. 230
11.12.8. CmdSN ................................................ 230
11.12.9. ExpStatSN ............................................ 231
11.12.10. Login Parameters .................................... 231
11.13. Login Response ........................................... 231
11.13.1. Version-max .......................................... 232
11.13.2. Version-active ....................................... 233
11.13.3. TSIH ................................................. 233
11.13.4. StatSN ............................................... 233
11.13.5. Status-Class and Status-Detail ....................... 233
11.13.6. T (Transit) bit ...................................... 237
11.13.7. C (Continue) Bit ..................................... 238
11.13.8. Login Parameters ..................................... 238
11.14. Logout Request ........................................... 238
11.14.1. Reason Code .......................................... 241
11.14.2. TotalAHSLength and DataSegmentLength ................. 242
11.14.3. CID .................................................. 242
11.14.4. ExpStatSN ............................................ 242
11.14.5. Implicit termination of tasks ........................ 242
11.15. Logout Response .......................................... 243
11.15.1. Response ............................................. 244
11.15.2. TotalAHSLength and DataSegmentLength ................. 245
Chadalapaka et al. Expires July 15, 2013 [Page 11]
iSCSI (Consolidated) 1/13/13
11.15.3. Time2Wait ............................................ 245
11.15.4. Time2Retain .......................................... 245
11.16. SNACK Request ............................................ 246
11.16.1. Type ................................................. 247
11.16.2. Data Acknowledgement ................................. 248
11.16.3. Resegmentation ....................................... 248
11.16.4. Initiator Task Tag ................................... 249
11.16.5. Target Transfer Tag or SNACK Tag ..................... 249
11.16.6. BegRun ............................................... 250
11.16.7. RunLength ............................................ 250
11.17. Reject ................................................... 251
11.17.1. Reason ............................................... 252
11.17.2. DataSN/R2TSN ......................................... 253
11.17.3. StatSN, ExpCmdSN and MaxCmdSN ........................ 253
11.17.4. Complete Header of Bad PDU ........................... 254
11.18. NOP-Out .................................................. 254
11.18.1. Initiator Task Tag ................................... 255
11.18.2. Target Transfer Tag .................................. 255
11.18.3. Ping Data ............................................ 256
11.19. NOP-In ................................................... 257
11.19.1. Target Transfer Tag .................................. 258
11.19.2. StatSN ............................................... 258
11.19.3. LUN .................................................. 258
12. iSCSI Security Text Keys and Authentication Methods........... 259
12.1. AuthMethod ................................................ 259
12.1.1. Kerberos .............................................. 261
12.1.2. Secure Remote Password (SRP) .......................... 262
12.1.3. Challenge Handshake Authentication Protocol (CHAP) .... 263
13. Login/Text Operational Text Keys.............................. 266
13.1. HeaderDigest and DataDigest .............................. 266
13.2. MaxConnections ........................................... 269
13.3. SendTargets .............................................. 269
13.4. TargetName ............................................... 269
13.5. InitiatorName ............................................ 270
13.6. TargetAlias .............................................. 271
Chadalapaka et al. Expires July 15, 2013 [Page 12]
iSCSI (Consolidated) 1/13/13
13.7. InitiatorAlias ............................................ 271
13.8. TargetAddress ............................................. 272
13.9. TargetPortalGroupTag ...................................... 273
13.10. InitialR2T ............................................... 273
13.11. ImmediateData ............................................ 274
13.12. MaxRecvDataSegmentLength ................................. 275
13.13. MaxBurstLength ........................................... 276
13.14. FirstBurstLength ......................................... 276
13.15. DefaultTime2Wait ......................................... 277
13.16. DefaultTime2Retain ....................................... 277
13.17. MaxOutstandingR2T ........................................ 278
13.18. DataPDUInOrder ........................................... 278
13.19. DataSequenceInOrder ...................................... 279
13.20. ErrorRecoveryLevel ....................................... 279
13.21. SessionType .............................................. 280
13.22. The Private Extension Key Format ......................... 281
13.23. TaskReporting ............................................ 281
13.24. iSCSIProtocolLevel Negotiation ........................... 282
13.25. Obsoleted Keys ........................................... 282
13.26. X#NodeArchitecture ....................................... 283
13.26.1. Definition ........................................... 283
13.26.2. Implementation Requirements .......................... 284
14. Rationale for revised IANA Considerations..................... 285
15. IANA Considerations........................................... 287
Appendix A. Examples ............................................. 294
Read Operation Example .......................................... 294
Write Operation Example ......................................... 295
R2TSN/DataSN Use Examples ....................................... 295
CRC Examples .................................................... 299
Appendix B. Login Phase Examples ................................. 301
Appendix C. SendTargets Operation ................................ 311
Appendix D. Algorithmic Presentation of Error Recovery Classes ... 316
Chadalapaka et al. Expires July 15, 2013 [Page 13]
iSCSI (Consolidated) 1/13/13
D.2.1. Procedure Descriptions ................................. 318
Appendix E. Clearing Effects of Various Events on Targets ........ 335
Chadalapaka et al. Expires July 15, 2013 [Page 14]
iSCSI (Consolidated) 1/13/13
1. Introduction
The Small Computer Systems Interface (SCSI) is a popular family of
protocols for communicating with I/O devices, especially storage
devices. SCSI is a client-server architecture. Clients of a SCSI
interface are called "initiators". Initiators issue SCSI
"commands" to request services from components, logical units of a
server known as a "target". A "SCSI transport" maps the client-
server SCSI protocol to a specific interconnect. An Initiator is
one endpoint of a SCSI transport and a target is the other
endpoint.
The SCSI protocol has been mapped over various transports,
including Parallel SCSI, IPI, IEEE-1394 (firewire) and Fibre
Channel. These transports are I/O specific and have limited
distance capabilities.
The iSCSI protocol defined in this document describes a means of
transporting of the SCSI packets over TCP/IP, providing for an
interoperable solution which can take advantage of existing
Internet infrastructure, Internet management facilities and
address distance limitations.
Chadalapaka et al. Expires July 15, 2013 [Page 15]
iSCSI (Consolidated) 1/13/13
2. Acronyms, Definitions and Document Summary
2.1. Acronyms
Acronym Definition
--------------------------------------------------------------
3DES Triple Data Encryption Standard
ACA Auto Contingent Allegiance
AEN Asynchronous Event Notification
AES Advanced Encryption Standard
AH Additional Header (not the IPsec AH!)
AHS Additional Header Segment
API Application Programming Interface
ASC Additional Sense Code
ASCII American Standard Code for Information Interchange
ASCQ Additional Sense Code Qualifier
BHS Basic Header Segment
CBC Cipher Block Chaining
CD Compact Disk
CDB Command Descriptor Block
CHAP Challenge Handshake Authentication Protocol
CID Connection ID
CO Connection Only
CRC Cyclic Redundancy Check
CRL Certificate Revocation List
CSG Current Stage
CSM Connection State Machine
DES Data Encryption Standard
DNS Domain Name Server
DOI Domain of Interpretation
DVD Digital Versatile Disk
EDTL Expected Data Transfer Length
ESP Encapsulating Security Payload
EUI Extended Unique Identifier
FFP Full Feature Phase
FFPO Full Feature Phase Only
Gbps Gigabits per Second
HBA Host Bus Adapter
HMAC Hashed Message Authentication Code
I_T Initiator_Target
Chadalapaka et al. Expires July 15, 2013 [Page 16]
iSCSI (Consolidated) 1/13/13
I_T_L Initiator_Target_LUN
IANA Internet Assigned Numbers Authority
IB InfiniBand
ID Identifier
IDN Internationalized Domain Name
IEEE Institute of Electrical & Electronics Engineers
IETF Internet Engineering Task Force
IKE Internet Key Exchange
I/O Input-Output
IO Initialize Only
IP Internet Protocol
IPsec Internet Protocol Security
IPv4 Internet Protocol Version 4
IPv6 Internet Protocol Version 6
IQN iSCSI Qualified Name
iSCSI Internet SCSI
iSER iSCSI Extensions for RDMA
ISID Initiator Session ID
iSNS Internet Storage Name Service (see [RFC4171])
ITN iSCSI Target Name
ITT Initiator Task Tag
KRB5 Kerberos V5
LFL Lower Functional Layer
LTDS Logical-Text-Data-Segment
LO Leading Only
LU Logical Unit
LUN Logical Unit Number
MAC Message Authentication Codes
NA Not Applicable
NAA Network Address Authority
NIC Network Interface Card
NOP No Operation
NSG Next Stage
OS Operating System
PDU Protocol Data Unit
PKI Public Key Infrastructure
R2T Ready To Transfer
R2TSN Ready To Transfer Sequence Number
RDMA Remote Direct Memory Access
RFC Request For Comments
SAM SCSI Architecture Model
Chadalapaka et al. Expires July 15, 2013 [Page 17]
iSCSI (Consolidated) 1/13/13
SAM2 SCSI Architecture Model - 2
SAN Storage Area Network
SAS Serial Attached SCSI
SCSI Small Computer Systems Interface
SLP Service Location Protocol
SN Sequence Number
SNACK Selective Negative Acknowledgment - also
Sequence Number Acknowledgement for data
SPDTL SCSI-Presented Data Transfer Length
SPKM Simple Public-Key Mechanism
SRP Secure Remote Password
SSID Session ID
SW Session-Wide
TCB Task Control Block
TCP Transmission Control Protocol
TMF Task Management Function
TPGT Target Portal Group Tag
TSIH Target Session Identifying Handle
TTT Target Transfer Tag
UA Unit Attention
UFL Upper Functional Layer
ULP Upper Level Protocol
URN Uniform Resource Names
UTF Universal Transformation Format
WG Working Group
2.2. Definitions
- Alias: An alias string can also be associated with an iSCSI
Node. The alias allows an organization to associate a user-
friendly string with the iSCSI Name. However, the alias string is
not a substitute for the iSCSI Name.
- CID (Connection ID): Connections within a session are identified
by a connection ID. It is a unique ID for this connection within
the session for the initiator. It is generated by the initiator
and presented to the target during login requests and during
logouts that close connections.
- Connection: A connection is a TCP connection. Communication
between the initiator and target occurs over one or more TCP
Chadalapaka et al. Expires July 15, 2013 [Page 18]
iSCSI (Consolidated) 1/13/13
connections. The TCP connections carry control messages, SCSI
commands, parameters, and data within iSCSI Protocol Data Units
(iSCSI PDUs).
- I/O Buffer:A buffer that is used in a SCSI Read or Write
operation so SCSI data may be sent from or received into that
buffer. For a read or write data transfer to take place for a
task, an I/O Buffer is required on the initiator and at least one
is required on the
target.
- INCITS: INCITS stands for InterNational Committee of Information
Technology Standards. The INCITS has a broad standardization scope
within the field of Information and Communications Technologies
(ICT), encompassing storage, processing, transfer, display,
management, organization, and retrieval of information. INCITS
serves as ANSI's Technical Advisory Group for the ISO/IEC Joint
Technical Committee 1 (JTC 1). See http://www.incits.org.
- InfiniBand: An I/O architecture originally intended to replace
PCI and to address high performance server interconnectivity [IB].
- iSCSI Device: A SCSI Device using an iSCSI service delivery
subsystem. Service Delivery Subsystem is defined by [SAM2] as a
transport mechanism for SCSI commands and responses.
- iSCSI Initiator Name: The iSCSI Initiator Name specifies the
worldwide unique name of the initiator.
- iSCSI Initiator Node: The "initiator" device. The word
"initiator" has been appropriately qualified as either a port or a
device in the rest of the document when the context is ambiguous.
All unqualified usages of "initiator" refer to an initiator port
(or device) depending on the context.
- iSCSI Layer: This layer builds/receives iSCSI PDUs and
relays/receives them to/from one or more TCP connections that form
an initiator-target "session".
- iSCSI Name: The name of an iSCSI initiator or iSCSI target.
Chadalapaka et al. Expires July 15, 2013 [Page 19]
iSCSI (Consolidated) 1/13/13
- iSCSI Node: The iSCSI Node represents a single iSCSI initiator
or iSCSI target or a single instance of each. There are one or
more iSCSI Nodes within a Network Entity. The iSCSI Node is
accessible via one or more Network Portals. An iSCSI Node is
identified by its iSCSI Name. The separation of the iSCSI Name
from the addresses used by and for the iSCSI Node allows multiple
iSCSI nodes to use the same address, and the same iSCSI node to
use multiple addresses.
- iSCSI Target Name: The iSCSI Target Name specifies the worldwide
unique name of the target.
- iSCSI Target Node: The "target" device. The word "target" has
been appropriately qualified as either a port or a device in the
rest of the document when the context is ambiguous. All
unqualified usages of "target" refer to a target port (or device)
depending on the context.
- iSCSI Task: An iSCSI task is an iSCSI request for which a
response is expected.
- iSCSI Transfer Direction: The iSCSI transfer direction is
defined with regard to the initiator. Outbound or outgoing
transfers are transfers from the initiator to the target, while
inbound or incoming transfers are from the target to the
initiator.
- ISID: The initiator part of the Session Identifier. It is
explicitly specified by the initiator during Login.
- I_T nexus: According to [SAM2], the I_T nexus is a relationship
between a SCSI Initiator Port and a SCSI Target Port. For iSCSI,
this relationship is a session, defined as a relationship between
an iSCSI Initiator's end of the session (SCSI Initiator Port) and
the iSCSI Target's Portal Group. The I_T nexus can be identified
by the conjunction of the SCSI port names; that is, the I_T nexus
identifier is the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI
Target Name + ',t,'+ Portal Group Tag).
Chadalapaka et al. Expires July 15, 2013 [Page 20]
iSCSI (Consolidated) 1/13/13
- I_T_L nexus: An I_T_L nexus is a SCSI concept, and is defined as
the relationship between a SCSI Initiator Port, a SCSI Target
Port, and a Logical Unit (LU).
- NAA: Network Address Authority, a naming format defined by the
INCITS T11 Fibre Channel protocols [FC-FS3].
- Network Entity: The Network Entity represents a device or
gateway that is accessible from the IP network. A Network Entity
must have one or more Network Portals, each of which can be used
to gain access to the IP network by some iSCSI Nodes contained in
that Network Entity.
- Network Portal: The Network Portal is a component of a Network
Entity that has a TCP/IP network address and that may be used by
an iSCSI Node within that Network Entity for the connection(s)
within one of its iSCSI sessions. A Network Portal in an initiator
is identified by its IP address. A Network Portal in a target is
identified by its IP address and its listening TCP port.
- Originator: In a negotiation or exchange, the party that
initiates the negotiation or exchange.
- PDU (Protocol Data Unit): The initiator and target divide their
communications into messages. The term "iSCSI protocol data unit"
(iSCSI PDU) is used for these messages.
- Portal Groups: iSCSI supports multiple connections within the
same session; some implementations will have the ability to
combine connections in a session across multiple Network Portals.
A Portal Group defines a set of Network Portals within an iSCSI
Network Entity that collectively supports the capability of
coordinating a session with connections spanning these portals.
Not all Network Portals within a Portal Group need participate in
every session connected through that Portal Group. One or more
Portal Groups may provide access to an iSCSI Node. Each Network
Portal, as utilized by a given iSCSI Node, belongs to exactly one
portal group within that node.
Chadalapaka et al. Expires July 15, 2013 [Page 21]
iSCSI (Consolidated) 1/13/13
- Portal Group Tag: This 16-bit quantity identifies a Portal Group
within an iSCSI Node. All Network Portals with the same portal
group tag in the context of a given iSCSI Node are in the same
Portal Group.
- Recovery R2T: An R2T generated by a target upon detecting the
loss of one or more Data-Out PDUs through one of the following
means: a digest error, a sequence error, or a sequence reception
timeout. A recovery R2T carries the next unused R2TSN, but
requests all or part of the data burst that an earlier R2T (with a
lower R2TSN) had already requested.
- Responder: In a negotiation or exchange, the party that responds
to the originator of the negotiation or exchange.
- SAS: Serial Attached SCSI. The Serial Attached SCSI (SAS)
standard contains both a physical layer compatible with Serial
ATA, and protocols for transporting SCSI commands to SAS devices
and ATA commands to SATA devices [SAS].
- SCSI Device: This is the SAM2 term for an entity that contains
one or more SCSI ports that are connected to a service delivery
subsystem and supports a SCSI application protocol. For example, a
SCSI Initiator Device contains one or more SCSI Initiator Ports
and zero or more application clients. A Target Device contains one
or more SCSI Target Ports and one or more device servers and
associated logical units. For iSCSI, the SCSI Device is the
component within an iSCSI Node that provides the SCSI
functionality. As such, there can be, at most, one SCSI Device
within a given iSCSI Node. Access to the SCSI Device can only be
achieved in an iSCSI normal operational session. The SCSI Device
Name is defined to be the iSCSI Name of the node.
- SCSI Layer: This builds/receives SCSI CDBs (Command Descriptor
Blocks) and relays/receives them with the remaining command
execute [SAM2] parameters to/from the iSCSI Layer.
- Session: The group of TCP connections that link an initiator
with a target form a session (loosely equivalent to a SCSI I-T
nexus). TCP connections can be added and removed from a session.
Chadalapaka et al. Expires July 15, 2013 [Page 22]
iSCSI (Consolidated) 1/13/13
Across all connections within a session, an initiator sees one and
the same target.
- SCSI Port: This is the SAM2 term for an entity in a SCSI Device
that provides the SCSI functionality to interface with a service
delivery subsystem. For iSCSI, the definition of the SCSI
Initiator Port and the SCSI Target Port are different.
- SCSI Initiator Port: This maps to the endpoint of an iSCSI
normal operational session. An iSCSI normal operational session is
negotiated through the login process between an iSCSI initiator
node and an iSCSI target node. At successful completion of this
process, a SCSI Initiator Port is created within the SCSI
Initiator Device. The SCSI Initiator Port Name and SCSI Initiator
Port Identifier are both defined to be the iSCSI Initiator Name
together with (a) a label that identifies it as an initiator port
name/identifier and (b) the ISID portion of the session
identifier.
- SCSI Port Name: A name consisting of UTF-8 [RFC3629] encoding of
Unicode [UNICODE] characters and includes the iSCSI Name + 'i' or
't' + ISID or Portal Group Tag.
- SCSI-Presented Data Transfer Length (SPDTL): SPDTL is the
aggregate data length of the data that the SCSI layer logically
"presents" to the iSCSI layer for a Data-In or Data-Out transfer
in the context of a SCSI task. For a bidirectional task, there are
two SPDTL values -- one for Data-In and one for Data-Out. Note
that the notion of "presenting" includes immediate data per the
data transfer model in [SAM2], and excludes overlapping data
transfers, if any, requested by the SCSI layer.
- SCSI Target Port: This maps to an iSCSI Target Portal Group.
- SCSI Target Port Name and SCSI Target Port Identifier: These are
both defined to be the iSCSI Target Name together with (a) a label
that identifies it as a target port name/identifier and (b) the
portal group tag.
- SSID (Session ID): A session between an iSCSI initiator and an
iSCSI target is defined by a session ID that is a tuple composed
Chadalapaka et al. Expires July 15, 2013 [Page 23]
iSCSI (Consolidated) 1/13/13
of an initiator part (ISID) and a target part (Target Portal Group
Tag). The ISID is explicitly specified by the initiator at session
establishment. The Target Portal Group Tag is implied by the
initiator through the selection of the TCP endpoint at connection
establishment. The TargetPortalGroupTag key must also be returned
by the target as a confimation during connection establishment.
- T10: A technical committee within INCITS that develops standards
and technical reports on I/O interfaces, particularly the series
of SCSI (Small Computer Systems Interface) standards. See
http://www.t10.org.
- T11: A technical committee within INCITS responsible for
standards development in the areas of Intelligent Peripheral
Interface (IPI), High-Performance Parallel Interface (HIPPI) and
Fibre Channel (FC). See http://www.t11.org.
- Target Portal Group Tag: A numerical identifier (16-bit) for an
iSCSI Target Portal Group.
-Target Transfer Tag (TTT): An iSCSI protocol field used in a few
iSCSI PDUs (e.g. R2T, NOP-In) which is always sent from the target
to the initiator first and then quoted as a reference in
initiator-sent PDUs back to the target relating to the same
task/exchange. So effectively, TTT acts as an opaque handle to an
existing task/exchange to help target associate the incoming PDUs
from the initiator to the proper execution context.
- Third-party: A term used in this document as a qualifier to
nexus objects (I_T or I_T_L) and iSCSI sessions, to indicate that
these objects and sessions reap the side effects of actions that
take place in the context of a separate iSCSI session. One
example of a third-party session is an iSCSI session discovering
that its I_T_L nexus to an LU got reset due to an LU Reset
operation orchestrated via a separate I_T nexus.
- TSIH (Target Session Identifying Handle): A target assigned tag
for a session with a specific named initiator. The target
generates it during session establishment. Other than defining it
as a 16 bit binary string, its internal format and content are not
defined by this protocol but for the all 0 value that is reserved
Chadalapaka et al. Expires July 15, 2013 [Page 24]
iSCSI (Consolidated) 1/13/13
and used by the initiator to indicate a new session. It is given
to the target during additional connection establishment for the
same session.
2.3. Summary of Changes
1) Consolidated RFCs 3720, 3980, 4850 and 5048, and made the
necessary editorial changes
2) iSCSIProtocolLevel is specified as "1" in Section 13.24, and
added a related normative reference to [iSCSI-SAM] draft
3) Markers and related keys were removed
4) SPKM authentication and related keys were removed
5) Added a new Section 13.25 on responding to obsoleted keys
6) Have explicitly allowed initiator+target implementations
throughout the text
7) Clarified in Section 4.2.7 that implementations SHOULD NOT
rely on SLP-based discovery
8) Added UML diagrams and related conventions in Section 3
9) FastAbort implementation is made a "SHOULD" requirement in
Section 4.2.3.4 from the previous "MUST" requirement.
10) Clarified in Section 6.2 that validity of NotUnderstood
response depends on iSCSIProtocolLevel
11) Required in Section 4.2.7.1 that iSCSI Target Name must be
the same as iSCSI Initiator Name for SCSI (composite) devices
with both roles
12) Changed the "MUST NOT" to "should avoid&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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| (variable # of bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encoding of type=123 (0x7b) TLV with value 'x' (120 = 0x78): 007B
0005 7800 0000
Notation:
.. = octet string concatenation operation
H(x) = MD5 hash of x
H-64(x) = H(x) truncated by taking just first 64 bits of the
result.
5.1. Request TLVs (for use within unicast requests)
5.1.1. Request Network State TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: REQ-NETWORK-STATE (2) | Length: 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.2. Request Node Data TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: REQ-NODE-DATA (3) | Length: 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(node identifier) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stenberg & Barth Expires December 27, 2014 [Page 9]
Internet-Draft Home Networking Control Protocol June 2014
5.2. Data TLVs (for use in both multi- and unicast data)
5.2.1. Node Link TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: NODE-LINK (1) | Length: 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(node identifier) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.2. Network State TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: NETWORK-STATE (4) | Length: 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(H(node data TLV 1) .. H(node data TLV N)) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Node Data TLVs are ordered for hashing by octet comparison of the
corresponding node identifier hashes in ascending order.
5.2.3. Node State TLV
Stenberg & Barth Expires December 27, 2014 [Page 10]
Internet-Draft Home Networking Control Protocol June 2014
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: NODE-STATE (5) | Length: 44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(node identifier) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Milliseconds since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(node data TLV) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The whole network should have roughly the same idea about the time
since origination, i.e. even the originating router should increment
the time whenever it needs to send a new Node State TLV regarding
itself without changing the corresponding Node Data TLV. This age
value is not included within the Node Data TLV, however, as that is
immutable and potentially signed by the originating node at the time
of origination.
5.2.4. Node Data TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: NODE-DATA (6) | Length: >= 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(node identifier) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested TLVs containing node information |
The Node Public Key TLV (Section 5.2.5) SHOULD be always included if
signatures are ever used.
Stenberg & Barth Expires December 27, 2014 [Page 11]
Internet-Draft Home Networking Control Protocol June 2014
If signatures are in use, the Node Data TLV SHOULD also contain the
originator's own Signature TLV (Section 5.5.2).
5.2.5. Node Public Key TLV (within Node Data TLV)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: PUBLIC-KEY (7) | Length: >= 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Key (raw node identifier) |
Public key data for the node. Only relevant if signatures are used.
Can be used to verify that H(node identifier) in the received data
for the node equals H(public key), and that the Signature TLVs are
signed by appropriate public keys.
5.2.6. Neighbor TLV (within Node Data TLV)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: NEIGHBOR (8) | Length: 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| H(neighbor node identifier) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Link Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Link Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV indicates that the node in question vouches that the
specified neighbor is reachable by it on the local link id given.
This reachability may be unidirectional (if no unicast exchanges have
been performed with the neighbor). The presence of this TLV at least
guarantees that the node publishing it has received traffic from the
neighbor recently. For guaranteed bidirectional reachability,
existence of both nodes' matching Neighbor TLVs should be checked.
5.3. Custom TLV (within/without Node Data TLV)
Stenberg & Barth Expires December 27, 2014 [Page 12]
Internet-Draft Home Networking Control Protocol June 2014
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: CUSTOM-DATA (9) | Length: >= 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H-64(URI) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Data |
This TLV can be used to contain anything; the URI used should be
under control of the author of that specification. For example:
V=H-64('http://example.com/author/json-for-hncp') .. '{"cool": "json
extension!"}'
or
V=H-64('mailto:author@example.com') .. '{"cool": "json extension!"}'
5.4. Version TLV (within Node Data TLV)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: VERSION (10) | Length: >= 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-agent |
This TLV indicates which version of HNCP TLV binary structures is in
use by this particular node. All TLVs within node data from nodes
that do not publish version TLV, or with different Version value than
locally supported one MUST be ignored (but forwarded). The user-
agent is an optional human-readable UTF-8 string that can describe
e.g. current hnetd version. This draft describes Version=1 TLVs.
5.5. Authentication TLVs
5.5.1. Certificate-related TLVs
TBD; should be probably some sort of certificate ID to be used in a
lookup at most, as raw certificates will overflow easily IPv6 minimum
MTU.
Stenberg & Barth Expires December 27, 2014 [Page 13]
Internet-Draft Home Networking Control Protocol June 2014
5.5.2. Signature TLV
TLV with T=0xFFFF, V=(TBD) public key algorithm based signature of
all TLVs within current scope as well as the parent TLV header, if
any. The assumed signature key is private key matching the public
key of the the originator of node link TLV (if signature TLV is
within main body of message), or that of the originator of the node
data TLV (if signature TLV is within Node Data TLV)..
Given the ordering of TLVs, this TLV should be last one processed
within current scope.
6. Border Discovery and Prefix Assignment
Using Default Border Definition [I-D.kline-homenet-default-perimeter]
as a basis, this section defines border discovery algorithm specifics
derived from the edge router interactions described in the Basic
Requirements for IPv6 Customer Edge Routers [RFC7084]. The algorithm
is designed to work for both IPv4 and IPv6 (single or dual-stack).
In order to avoid conflicts between border discovery and homenet
routers running DHCP [RFC2131] or DHCPv6-PD [RFC3633] servers each
router MUST implement the following mechanism based on The User Class
Option for DHCP [RFC3004] or its DHCPv6 counterpart [RFC3315]
respectively into its DHCP and DHCPv6-logic:
A homenet router running a DHCP-client on a homenet-interface MUST
include a DHCP User-Class consisting of the ASCII-String
"HOMENET".
A homenet router running a DHCP-server on a homenet-interface MUST
ignore or reject DHCP-Requests containing a DHCP User-Class
consisting of the ASCII-String "HOMENET".
The border discovery auto-detection algorithm works as follows, with
evaluation stopping at first match:
1. If a fixed category is set for an interface, it MUST be used.
2. Any of the following conditions indicate an interface MUST be
considered external:
1. A delegated prefix could be acquired by running a
DHCPv6-client on the interface.
2. An IPv4-address could be acquired by running a DHCP-client on
the interface.
Stenberg & Barth Expires December 27, 2014 [Page 14]
Internet-Draft Home Networking Control Protocol June 2014
3. HNCP security is enabled and there are routers on the
interface which could not be authenticated.
3. As default fallback, interface MUST be considered internal.
A router SHOULD allow setting a category of either auto-detected,
internal or external for each interface which is suitable for both
internal and external connections. In addition it MAY offer further
categories which modify the local router behavior, such as:
Guest category: This is a specialization of the internal category
which declares an interface used for untrusted clients. The
router MUST NOT send or accept HNCP messages on these interfaces.
Clients connected to these interfaces MUST NOT be able to reach
devices inside the home network by default and instead SHOULD only
be able to reach the internet.
Ad-hoc category: This is a specialization of the internal category
which declares an interface to be in ad-hoc mode. This indicates
to HNCP applications such as prefix assignment that links on this
interface are potentially non-transitive.
Hybrid category: This is a specialization of the internal category
in which the router still accepts external connections but does
not do border discovery. It is assumed that the link is under
control of a legacy, trustworthy non-HNCP router, still within the
same home network. Detection of this category automatically is
out of scope for this document, and therefore it MAY be supported
only via manual configuration on a per-router basis.
A homenet router SHOULD provide basic connectivity to legacy CERs
[RFC7084] connected to internal interfaces in order to allow
coexistence with existing devices.
Each router MUST continuously scan each active interface that does
not have a fixed category in order to dynamically reclassify it if
necessary. The router therefore runs an appropriately configured
DHCP and DHCPv6-client as long as the interface is active including
states where it considers the interface to be internal. The router
SHOULD wait for a reasonable time period (5 seconds as a possible
default) in which the DHCP-clients can acquire a lease before
treating a newly activated or previously external interface as
internal. Once it treats a certain interface as internal it MUST
start forwarding traffic with appropriate source addresses between
its internal interfaces and allow internal traffic to reach external
networks. Once a router detects an interface to be external it MUST
stop any previously enabled internal forwarding. In addition it
SHOULD announce the acquired information for use in the homenet as
Stenberg & Barth Expires December 27, 2014 [Page 15]
Internet-Draft Home Networking Control Protocol June 2014
described in later sections of this draft if the interface appears to
be connected to an external network.
To distribute an external connection in the homenet an edge router
announces one or more delegated prefixes and associated DHCP(v6)-
encoded auxiliary information like recursive DNS-servers. Each
external connection is announced using one container-TLV as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: EXTERNAL-CONNECTION (41)| Length: > 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested TLVs |
Auxiliary connectivity information is encoded as a stream of
DHCPv6-attributes or DHCP-attributes placed inside a TLV of type
EXTERNAL-CONNECTION or DELEGATED-PREFIX (for IPv6 prefix-specific
information). There MUST NOT be more than one instance of this TLV
inside a container and the order of the DHCP(v6)-attributes contained
within it MUST be preserved as long as the information contained does
not change. The TLVs are encoded as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: DHCPV6-DATA (45) | Length: > 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCPv6 attribute stream |
and
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: DHCP-DATA (44) | Length: > 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP attribute stream |
Each delegated prefix is encoded using one TLV inside an EXTERNAL-
CONNECTION TLV. For external IPv4 connections the prefix is encoded
in the form of an IPv4-mapped address [RFC4291] and is usually from a
private address range [RFC1918]. The related TLV is defined as
follows.
Stenberg & Barth Expires December 27, 2014 [Page 16]
Internet-Draft Home Networking Control Protocol June 2014
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: DELEGATED-PREFIX (42) | Length: >= 13 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid until (milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred until (milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | |
+-+-+-+-+-+-+-+-+ Prefix Address [+ nested TLVs] +
| |
Valid until is the time in milliseconds the delegated prefix is
valid. The value is relative to the point in time the TLV is
first announced.
Preferred until is the time in milliseconds the delegated prefix
is preferred. The value is relative to the point in time the TLV
is first announced.
Prefix length specifies the number of significant bits in the
prefix.
Prefix address is of variable length and contains the significant
bits of the prefix padded with zeroes up to the next byte
boundary.
Nested TLVs might contain prefix-specific information like
DHCPv6-options.
In order for routers to use the distributed information, prefixes and
addresses have to be assigned to the interior links of the homenet.
A router MUST therefore implement the algorithm defined in Prefix and
Address Assignment in a Home Network
[I-D.pfister-homenet-prefix-assignment]. In order to announce the
assigned prefixes the following TLVs are defined.
Each assigned prefix is given to an interior link and is encoded
using one TLVs. Assigned IPv4 prefixes are stored as mapped
IPv4-addresses. The TLV is defined as follows:
Stenberg & Barth Expires December 27, 2014 [Page 17]
Internet-Draft Home Networking Control Protocol June 2014
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: ASSIGNED-PREFIX (43) | Length: >= 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R. |A| Pref. | Prefix Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix Address +
| |
Link Identifier is the local HNCP identifier of the link the
prefix is assigned to.
R. is reserved for future additions and MUST be set to 0 when
creating TLVs and ignored when parsing them.
A is the authoritative flag which indicates that an assignment is
enforced and ignores usual collision detection rules.
Pref. describes the preference of the assignment and can be used
to differentiate the importance of a given assignment over others.
Prefix length specifies the number of significant bits in the
prefix.
Prefix address is of variable length and contains the significant
bits of the prefix padded with zeroes up to the next byte
boundary.
In some cases (e.g. IPv4) the set of addresses is very limited and
stateless mechanisms are not really suitable for address assignment.
Therefore HNCP can manage router address in these cases by itself.
Each router assigning an address to one of its interfaces announces
one TLV of the following kind:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: ROUTER-ADDRESS (46) | Length: 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Router Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stenberg & Barth Expires December 27, 2014 [Page 18]
Internet-Draft Home Networking Control Protocol June 2014
Link Identifier is the local HNCP identifier of the link the
address is assigned to.
Router Address is the address assigned to one of the router
interfaces.
7. DNS-based Service Discovery
Service discovery is generally limited to a local link.
[I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf] defines a
mechanism to automatically extended DNS-based service discovery
across multiple links within the home automatically. Following TLVs
MAY be used to provide transport for that specification.
7.1. DNS Delegated Zone TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: DNS-DELEGATED-ZONE (50) | Length: >= 21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |S|B| |
+-+-+-+-+-+-+-+-+ Zone (DNS label sequence - variable length) |
| |
7.2. Domain Name TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: DOMAIN-NAME (51) | Length: >= 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain (DNS label sequence - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.3. Router Name TLV
Stenberg & Barth Expires December 27, 2014 [Page 19]
Internet-Draft Home Networking Control Protocol June 2014
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: ROUTER-NAME (52) | Length: >= 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name (not null-terminated - variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8. Routing support
8.1. Protocol Requirements
In order to be advertised for use within the Homenet, a routing
protocol MUST:
Comply with Requirements and Use Cases for Source/Destination
Routing [I-D.baker-rtgwg-src-dst-routing-use-cases].
Be configured with suitable defaults or have an auto-configuration
mechanism (e.g. [I-D.acee-ospf-ospfv3-autoconfig]) such that it
will run in a Homenet without requiring specific configuration
from the Home user.
A router MUST NOT announce that it supports a certain routing
protocol if its implementation of the routing protocol does not meet
these requirements, e.g. it does not implement extensions that are
necessary for compliance.
8.2. Announcement
Each router SHOULD announce all routing protocols that it is capable
of supporting in the Homenet. It SHOULD assign a preference value
for each protocol that indicates its desire to use said protocol over
other protocols it supports and SHOULD make these values
configurable.
Each router includes one HNCP TLV of type ROUTING-PROTOCOL for every
such routing protocol. This TLV is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: ROUTING-PROTOCOL (60) | Length: 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol ID is one of:
Stenberg & Barth Expires December 27, 2014 [Page 20]
Internet-Draft Home Networking Control Protocol June 2014
0 = reserved
1 = Babel (dual-stack)
2 = OSPFv3 (dual-stack)
3 = IS-IS (dual-stack)
4 = RIP (dual-stack)
Preference is a value from 0 to 255. If a router is neutral about
a routing protocol it SHOULD use the value 128, otherwise a lower
value indicating lower preference or a higher value indicating
higher preference respectively.
8.3. Protocol Selection
When HNCP detects that a router has joined or left the Homenet it
MUST examine all advertised routing protocols and preference values
from all routers in the Homenet in order to find the one routing
protocol which:
1. Is understood by all routers in the homenet
2. Has the highest preference value among all routers (calculated as
sum of preference values)
3. Has the highest protocol ID among those with the highest
preference
If the router protocol selection results in the need to change from
one routing protocol to another on the homenet, the router MUST stop
the previously running protocol, remove associated routes, and start
the new protocol in a graceful manner. If there is no common routing
protocol available among all Homenet routers, routers MUST utilize
the Fallback Mechanism (Section 8.4).
8.4. Fallback Mechanism
In cases where there is no commonly supported routing protocol
available the following fallback algorithm is run to setup routing
and preserve interoperability among the homenet. While not intended
to replace a routing protocol, this mechanism provides a valid - but
not necessarily optimal - routing topology. This algorithm uses the
node and neighbor state already synchronized by HNCP, and therefore
does not require any additional protocol message exchange.
Stenberg & Barth Expires December 27, 2014 [Page 21]
Internet-Draft Home Networking Control Protocol June 2014
1. Interpret the neighbor information received via HNCP as a graph
of connected routers.
2. Use breadth-first traversal to determine the next-hop and hop-
count in the path to each router in the homenet:
1. Start the traversal with the immediate neighbors of the
router running the algorithm.
2. Always visit the immediate neighbors of a router in ascending
order of their router ID.
3. Never visit a router more often than once.
3. For each delegated prefix P of any router R in the homenet:
Create a default route via the next-hop for R acquired in #2.
Each such route MUST be source-restricted to only apply to
traffic with a source address within P and its metric MUST
reflect the hop-count to R.
4. For each assigned prefix A of a router R: Create a route to A via
the next-hop for R acquired in #2. Each such route MUST NOT be
source-restricted.
5. For the first router R visited in the traversal announcing an
IPv4-uplink: Create a default IPv4-route via the next-hop for R
acquired in #2.
6. For each assigned IPv4-prefix A of a router R: Create an
IPv4-route to A via the next-hop for R acquired in #2.
9. Security Considerations
General security issues for Home Networks are discussed at length in
[I-D.ietf-homenet-arch]. The protocols used to setup IP in home
networks today have very little security enabled within the control
protocol itself. For example, DHCP has defined [RFC3118] to
authenticate DHCP messages, but this is very rarely implemented in
large or small networks. Further, while PPP can provide secure
authentication of both sides of a point to point link, it is most
often deployed with one-way authentication of the subscriber to the
ISP, not the ISP to the subscriber. HNCP aims to make security as
easy as possible for the implementer by including built-in
capabilities for authentication of node data being exchanged as well
as the protocol messages themselves, but it is ultimately up to the
shipping system to take advantage of the protocol constructs defined.
Stenberg & Barth Expires December 27, 2014 [Page 22]
Internet-Draft Home Networking Control Protocol June 2014
HNCP is designed to integrate with trusted bootstrapping
[I-D.behringer-homenet-trust-bootstrap] including the ability to
authenticate messages between nodes. This authentication can be used
to securely define a border as well as protect against malicious
attacks and spoofing attempts from inside or outside the border.
HNCP itself sends messages as (possibly authenticated) clear text
which is as secure, or insecure, as the security of the link below as
discussed in [I-D.kline-homenet-default-perimeter]. When no unique
public key is available, a hardware fingerprint or equivalent to
identify routers must be available for use by HNCP.
As HNCP messages are sent over UDP/IP, IPsec may be used for
confidentiality or additional message authentication. However, this
requires manually keyed IPsec per-port granularity for port IANA-UDP-
PORT UDP traffic. Also, a pre-shared key has to be utilized in this
case given IKE cannot be used with multicast traffic.
If no router can be trusted and additional guarantees about source of
node status updates is necessary, real public and private keys should
be used to create signatures and verify them in HNCP on both on per-
node data TLVs as well as across the entire HNCP message. In this
mode, care must be taken in rate limiting verification of invalid
packets, as otherwise denial of service may occur due to exhaustion
of computation resources.
As a performance optimization, instead of providing signatures for
actual node data and the protocol messages themselves, it is also
possible to provide signatures just for protocol messages. While
this means it is no longer possible to verify the original source of
the node data itself, as long as the set of routers is trusted (i.e.,
no router in the set has itself been hacked to provide malicious node
data) then one can assume the node data is trusted because the router
is trusted and the data arrived in a protected protocol message.
10. IANA Considerations
IANA should set up a registry (policy TBD) for HNCP TLV types, with
following initial contents:
0: Reserved (should not happen on wire)
1: Node link
2: Request network state
3: Request node data
Stenberg & Barth Expires December 27, 2014 [Page 23]
Internet-Draft Home Networking Control Protocol June 2014
4: Network state
5: Node state
6: Node data
7: Node public key
8: Neighbor
9: Custom
10: Version
41: External connection
42: Delegated prefix
43: Assigned prefix
44: DHCP-data
45: DHCPv6-data
46: Router-address
50: DNS Delegated Zone
51: Domain name
52: Node name
60: Routing protocol
65535: Signature
HNCP will also require allocation of a UDP port number IANA-UDP-PORT,
as well as IPv6 link-local multicast address IANA-MULTICAST-ADDRESS.
11. References
11.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, March 2011.
Stenberg & Barth Expires December 27, 2014 [Page 24]
Internet-Draft Home Networking Control Protocol June 2014
[I-D.pfister-homenet-prefix-assignment]
Pfister, P., Paterson, B., and J. Arkko, "Prefix and
Address Assignment in a Home Network", draft-pfister-
homenet-prefix-assignment-01 (work in progress), May 2014.
[I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf]
Stenberg, M., "Auto-Configuration of a Network of Hybrid
Unicast/Multicast DNS-Based Service Discovery Proxy
Nodes", draft-stenberg-homenet-dnssd-hybrid-proxy-
zeroconf-01 (work in progress), June 2014.
11.2. Informative references
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
November 2013.
[RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis,
A., Beser, B., and J. Privat, "The User Class Option for
DHCP", RFC 3004, November 2000.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[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.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[I-D.ietf-homenet-arch]
Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
"IPv6 Home Networking Architecture Principles", draft-
ietf-homenet-arch-13 (work in progress), March 2014.
Stenberg & Barth Expires December 27, 2014 [Page 25]
Internet-Draft Home Networking Control Protocol June 2014
[I-D.troan-homenet-sadr]
Troan, O. and L. Colitti, "IPv6 Multihoming with Source
Address Dependent Routing (SADR)", draft-troan-homenet-
sadr-01 (work in progress), September 2013.
[I-D.behringer-homenet-trust-bootstrap]
Behringer, M., Pritikin, M., and S. Bjarnason,
"Bootstrapping Trust on a Homenet", draft-behringer-
homenet-trust-bootstrap-02 (work in progress), February
2014.
[I-D.baker-rtgwg-src-dst-routing-use-cases]
Baker, F., "Requirements and Use Cases for Source/
Destination Routing", draft-baker-rtgwg-src-dst-routing-
use-cases-00 (work in progress), August 2013.
[I-D.kline-homenet-default-perimeter]
Kline, E., "Default Border Definition", draft-kline-
homenet-default-perimeter-00 (work in progress), March
2013.
[I-D.acee-ospf-ospfv3-autoconfig]
Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration",
draft-acee-ospf-ospfv3-autoconfig-03 (work in progress),
July 2012.
11.3. URIs
[2] http://www.openwrt.org
[3] http://www.homewrt.org/doku.php?id=run-conf
Appendix A. Some Outstanding Issues
Should we use MD5 hashes, or EUI-64 node identifier to identify
nodes?
Is there a case for non-link-local unicast? Currently explicitly
stating this is link-local only protocol.
Consider if using Trickle with k=1 really pays off, as we need to do
reachability checks if layer 2 does not provide them periodically in
any case. Using Trickle with k=inf would remove the need for unicast
reachability checks, but at cost of extra multicast traffic. On the
other hand, N*(N-1)/2 unicast reachability checks when lot of routers
share a link is not appealing either.
Stenberg & Barth Expires December 27, 2014 [Page 26]
Internet-Draft Home Networking Control Protocol June 2014
Should we use something else than MD5 as hash? It IS somewhat
insecure; however signature stuff (TBD) should rely on it mainly for
security in any case, and MD5 is used in a non-security role.
Valid and preferred are now 32 bit millisecond and you cannot even
represent a month in them; is this enough? Or should we switch to 32
bit seconds (or 64 bit milliseconds)?
Appendix B. Some Obvious Questions and Answers
Q: Why not use TCP?
A: It does not address the node discovery problem. It also leads to
N*(N-1)/2 connections when N nodes share a link, which is awkward.
Q: Why not multicast-only?
A: It would require defining application level fragmentation scheme.
Hopefully the data amounts used will stay small so we just trust
unicast UDP to handle 'big enough' packets to contain single node's
TLV data. On some link layers unicast is also much more reliable
than multicast, especially for large packets.
Q: Why so long IDs? Why real hash even in insecure mode?
A: Scalability of protocol is not really affected by using real
(=cryptographic) hash function.
Q: Why trust IPv6 fragmentation in unicast case? Why not do L7
fragmentation?
A: Because it will be there for a while at least. And while PMTU et
al may be problems on open internet, in a home network environment
UDP fragmentation should NOT be broken in the foreseeable future.
Q: Should there be nested container syntax that is actually self-
describing? (i.e. type flag that indicates container, no body except
sub-TLVs?)
A: Not for now, but perhaps valid design.. TBD.
Q: Why not doing (performance thing X, Y or Z)?
A: This is designed mostly to be minimal (only timers Trickle ones;
everything triggered by Trickle-driven messages or local state
changes). However, feel free to suggest better (even more minimal)
design which works.
Stenberg & Barth Expires December 27, 2014 [Page 27]
Internet-Draft Home Networking Control Protocol June 2014
Appendix C. Changelog
draft-ietf-homenet-hncp-01: Added (MAY) guest, ad-hoc, hybrid
categories for interfaces. Removed old hnetv2 reference, and now
pointing just to OpenWrt + github. Fixed synchronization algorithm
to spread also same update number, but different data hash case.
Made purge step require bidirectional connectivity between nodes when
traversing the graph. Edited few other things to be hopefully
slightly clearer without changing their meaning.
draft-ietf-homenet-hncp-00: Added version TLV to allow for TLV
content changes pre-RFC without changing IDs. Added link id to
assigned address TLV.
Appendix D. Draft source
As usual, this draft is available at https://github.com/fingon/ietf-
drafts/ in source format (with nice Makefile too). Feel free to send
comments and/or pull requests if and when you have changes to it!
Appendix E. Acknowledgements
Thanks to Ole Troan, Pierre Pfister, Mark Baugher, Mark Townsley and
Juliusz Chroboczek for their contributions to the draft.
Authors' Addresses
Markus Stenberg
Helsinki 00930
Finland
Email: markus.stenberg@iki.fi
Steven Barth
Email: cyrus@openwrt.org
Stenberg & Barth Expires December 27, 2014 [Page 28]