Liaison statement
Response to Liaison 1546

State Posted
Posted Date 2018-04-04
From Group IAB
From Contact Cindy Morgan
To Group ITU-T-SG-20
To Contacts tsbsg20@itu.int
CcThe IAB Chair
itu-t-liaison@iab.org
The IAB Executive Director
The IAB
Scott Mansfield
Response Contact The IAB Chair
The IAB Executive Director
Purpose In response
Attachments Response to Liaison 1546
Liaisons referred by this one LS on IPv6 work items
Body
The Internet Architecture Board (IAB) thanks the ITU-T for calling our
attention to the Proposed Consolidated Draft Recommendation Y.IPv6RefModel
“Reference Model of IPv6 Addressing Plan for Internet of Things Deployment”
(Q1/20 e-meeting of 23 February 2017), per Liaison 1546.

Some members of the IETF community pointed out that there was a draft under
discussion in ITU-T SG20, but it was not included in the liaison statement.
Since that document is not public, it has not enjoyed community review from the
IAB or the IETF. Comments on several IETF Working Group mailing lists,
including IPv6 over Networks of Resource-constrained nodes (6lo), IPv6
Maintenance (6man), and IPv6 Operations (v6ops), expressed interest in this
work based on the liaison statement, but did not draft any response; the
request may have been too vague.

Based on limited knowledge of the Study Group’s current work, we can provide
only broad input to the process.

1.     The Internet Protocol version 6 Specification has been published as a
Standard with RFC 8200. The IPv6 Address Architecture is specified in RFC 4291,
with other documents detailing specific aspects of addressing.

2.     RFC 6177 “IPv6 Address Assignment to End Sites” recommends no particular
prefix length. No particular prefix length has been accepted as a best
practice. We have observed:

Residential users receive prefix delegations of /48, /56, /60, or /64,
according to their ISP’s policy. Based on potentially small subnets of very
large address space, IoT devices should be able to acquire IPv6 addresses, but
may not be able to have a dedicated subnet.

Businesses receive prefix delegations which may be the same size as residential
users, or may be a /48 per site, or may get a larger allocation from their RIR.

3.     Since there is no commonly accepted best practice, this work item must
be careful not to reserve bits or prefixes from the routing prefix assigned by
another organization (whether RIR, ISP, or local administrator). Such a
reservation would reduce the addressing available to the network operator or
administrator, and would stray beyond the limited scope of IoT addressing to
impacting all network address management.  That impact does not seem warranted
by this scope.

4.      It is not clear whether the work described encompasses IPv6-IPv4
translation; the IETF has published several documents describing transition
mechanisms. Specifically related to addressing, the IETF has published several
documents on how to construct the address:

RFC 6052 “IPv6 Addressing of IPv4/IPv6 Translators”
RFC 7915 “IP/ICMP Translation Algorithm”
RFC 7755 “SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center
Environments.” 5.     Any addressing plan, or address architecture, should
avoid embedding meaning in the address. Not only can it lead to mismatches if
the meaning changes, but there are security and privacy concerns. See, for
instance: RFC 7136 “Significance of IPv6 Interface Identifiers” RFC 8065
“Privacy Considerations for IPv6 Adaptation-Layer Mechanisms” RFC 7721
“Security and Privacy Considerations for IPv6 Address Generation Mechanisms” 6.
    If location information is needed, we note that the IETF has published
Geopriv in RFC 6280 “An Architecture for Location and Location Privacy in
Internet Applications” and related documents.

This is a short list of some possible considerations in an address plan, and is
not exhaustive. The IAB recommends that a draft of the proposed Reference Model
of IPv6 Addressing Plan for Internet of Things Deployment be made available for
public review before final publication, and would be happy to facilitate the
arrangement of that review within the IETF working groups mentioned above.