Skip to main content

Analysis of the 64-bit Boundary in IPv6 Addressing
draft-ietf-6man-why64-08

Revision differences

Document history

Date Rev. By Action
2015-01-12
08 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-12-22
08 Robert Sparks Notification list changed to 6man-chairs@tools.ietf.org, draft-ietf-6man-why64@tools.ietf.org, "Robert M. Hinden" <bob.hinden@gmail.com> from 6man-chairs@tools.ietf.org, draft-ietf-6man-why64@tools.ietf.org
2014-12-22
08 Robert Sparks Document shepherd changed to Robert M. Hinden
2014-12-19
08 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-12-02
08 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-11-03
08 Cindy Morgan IESG state changed to RFC Ed Queue from Approved-announcement sent
2014-11-03
08 (System) RFC Editor state changed to EDIT
2014-11-03
08 (System) Announcement was received by RFC Editor
2014-11-03
08 (System) IANA Action state changed to No IC
2014-11-03
08 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed
2014-11-03
08 Amy Vezza IESG has approved the document
2014-11-03
08 Amy Vezza Closed "Approve" ballot
2014-10-31
08 Brian Haberman Ballot writeup was changed
2014-10-31
08 Brian Haberman Ballot approval text was generated
2014-10-31
08 Naveen Khan New revision available
2014-10-30
07 Cindy Morgan IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2014-10-30
07 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2014-10-30
07 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2014-10-29
07 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2014-10-29
07 Ted Lemon [Ballot Position Update] New position, Yes, has been recorded for Ted Lemon
2014-10-29
07 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2014-10-29
07 Alissa Cooper
[Ballot comment]
This is a nice document, thanks for taking the time to write it.

= Section 1 =
"The bits in the IID have …
[Ballot comment]
This is a nice document, thanks for taking the time to write it.

= Section 1 =
"The bits in the IID have no meaning and the entire identifier should
  be treated as an opaque value [RFC7136]."

I understand what this means based on RFC7136, but it seems like it would be a little more clear to re-use the language from that document directly, e.g.,

"The bits in the IID may have significance only in the process of deriving the IID and once it is derived the entire identifier should be treated as an opaque value [RFC7136]."

= Section 4.5 =
This is probably not worth mentioning in the draft, but I'll write it down since the thought occurred to me: it's conceivable to argue that there could be a privacy benefit of shortening the IID, if it became so short that a hardware address could not be embedded in it. This benefit is quite obviously outweighed by the drawbacks you already describe in this section I think, but just food for thought.
2014-10-29
07 Alissa Cooper [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper
2014-10-29
07 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2014-10-29
07 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2014-10-29
07 Kathleen Moriarty [Ballot comment]
The SecDir review looks good, thank you for your work on the draft. 
https://www.ietf.org/mail-archive/web/secdir/current/msg05118.html
2014-10-29
07 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2014-10-29
07 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2014-10-29
07 Adrian Farrel
[Ballot comment]
Section 4.2

  o  Router implementations: Router implementors might interpret IETF
      standards such as [RFC6164] and [RFC7136 …
[Ballot comment]
Section 4.2

  o  Router implementations: Router implementors might interpret IETF
      standards such as [RFC6164] and [RFC7136] to indicate that

Maybe avoid any accidental confusion by using "specifications" rather
than "standards"
2014-10-29
07 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2014-10-27
07 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2014-10-23
07 Robert Sparks Request for Telechat review by GENART Completed: Ready. Reviewer: Robert Sparks.
2014-10-23
07 Jean Mahoney Request for Telechat review by GENART is assigned to Robert Sparks
2014-10-23
07 Jean Mahoney Request for Telechat review by GENART is assigned to Robert Sparks
2014-10-20
07 Brian Haberman Ballot approval text was generated
2014-10-19
07 Brian Carpenter IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2014-10-19
07 Brian Carpenter New version available: draft-ietf-6man-why64-07.txt
2014-10-14
06 Robert Sparks Request for Telechat review by GENART Completed: Ready. Reviewer: Robert Sparks.
2014-10-13
06 Brian Haberman Removed telechat returning item indication
2014-10-13
06 Brian Haberman Telechat date has been changed to 2014-10-30 from 2014-10-16
2014-10-08
06 Jean Mahoney Request for Telechat review by GENART is assigned to Robert Sparks
2014-10-08
06 Jean Mahoney Request for Telechat review by GENART is assigned to Robert Sparks
2014-10-02
06 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Melinda Shore.
2014-10-02
06 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2014-10-02
06 Brian Haberman Placed on agenda for telechat - 2014-10-16
2014-10-02
06 Brian Haberman IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2014-10-02
06 Brian Haberman Ballot has been issued
2014-10-02
06 Brian Haberman [Ballot Position Update] New position, Yes, has been recorded for Brian Haberman
2014-10-02
06 Brian Haberman Created "Approve" ballot
2014-10-02
06 Brian Haberman Ballot writeup was changed
2014-10-02
06 Brian Haberman Changed consensus to Yes from Unknown
2014-10-02
06 Brian Haberman IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup::AD Followup
2014-10-01
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-10-01
06 Brian Carpenter IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2014-10-01
06 Brian Carpenter New version available: draft-ietf-6man-why64-06.txt
2014-09-30
05 Brian Haberman IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup
2014-09-30
05 (System) IESG state changed to Waiting for Writeup from In Last Call
2014-09-29
05 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Ron Bonica.
2014-09-29
05 Robert Sparks Request for Last Call review by GENART Completed: Ready. Reviewer: Robert Sparks.
2014-09-24
05 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2014-09-24
05 Amanda Baber
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-6man-why64-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-6man-why64-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.
2014-09-23
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Melinda Shore
2014-09-23
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Melinda Shore
2014-09-23
05 Tero Kivinen Assignment of request for Last Call review by SECDIR to Adam Montville was rejected
2014-09-19
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Ron Bonica
2014-09-19
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Ron Bonica
2014-09-18
05 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2014-09-18
05 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2014-09-18
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Adam Montville
2014-09-18
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Adam Montville
2014-09-16
05 Amy Vezza IANA Review state changed to IANA - Review Needed
2014-09-16
05 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Analysis of the 64-bit Boundary …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Analysis of the 64-bit Boundary in IPv6 Addressing) to Informational RFC


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'Analysis of the 64-bit Boundary in IPv6 Addressing'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-09-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The IPv6 unicast addressing format includes a separation between the
  prefix used to route packets to a subnet and the interface identifier
  used to specify a given interface connected to that subnet.
  Currently the interface identifier is defined as 64 bits long for
  almost every case, leaving 64 bits for the subnet prefix.  This
  document describes the advantages of this fixed boundary and analyses
  the issues that would be involved in treating it as a variable
  boundary.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-why64/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-why64/ballot/


No IPR declarations have been submitted directly on this I-D.


2014-09-16
05 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2014-09-16
05 Brian Haberman Last call was requested
2014-09-16
05 Brian Haberman Last call announcement was generated
2014-09-16
05 Brian Haberman Ballot approval text was generated
2014-09-16
05 Brian Haberman Ballot writeup was generated
2014-09-16
05 Brian Haberman IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2014-09-15
05 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-09-15
05 Brian Carpenter New version available: draft-ietf-6man-why64-05.txt
2014-09-15
04 Brian Haberman IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2014-09-11
04 Brian Haberman IESG state changed to AD Evaluation from Publication Requested
2014-09-10
04 Bob Hinden
Write up for  "Analysis of the 64-bit Boundary in IPv6 Addressing"
                     

(1) What type …
Write up for  "Analysis of the 64-bit Boundary in IPv6 Addressing"
                     

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the
proper type of RFC? Is this type of RFC indicated in the title page
header?

    Informational, as indicated in the header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

    The IPv6 unicast addressing format includes a separation between the
    prefix used to route packets to a subnet and the interface identifier
    used to specify a given interface connected to that subnet.
    Currently the interface identifier is defined as 64 bits long for
    almost every case, leaving 64 bits for the subnet prefix.  This
    document describes the advantages of this fixed boundary and analyses
    the issues that would be involved in treating it as a variable
    boundary.

Working Group Summary:

  This document generated a very active discussion on the mailing list and
  in face to face discussions.  There is a strong consensus to publish it
  as an Informational RFC.

Document Quality:

  The document had strong support in the working group and has undergone
  three detailed reviews.  It is ready for publication.

Personnel:

  Bob Hinden is the Document Shepherd
  Brian Haberman is the Responsable AD

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  Mark Smith, Steven Blake and Ole Troan did reviews of the document
  that resulted in several improvements.    The document is ready for
  publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

  Each author has confirmed this.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures have been filed.

(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

  Strong and broad consensus in the working group.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  No serious issues.  There is a informational reference to an expired
  draft and one draft has a newer version, the RFC-Editor can resolve
  these.

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  N/A

(13) Have all references within this document been identified as either
normative or informative?

  Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  All Normative references are RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  N/A.  This draft is meant for Informational status.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

  No other RFCs are changed.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  This document requests no action by IANA.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  N/A

2014-09-10
04 Bob Hinden State Change Notice email list changed to 6man-chairs@tools.ietf.org, draft-ietf-6man-why64@tools.ietf.org
2014-09-10
04 Bob Hinden Responsible AD changed to Brian Haberman
2014-09-10
04 Bob Hinden IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2014-09-10
04 Bob Hinden IESG state changed to Publication Requested
2014-09-10
04 Bob Hinden IESG process started in state Publication Requested
2014-09-10
04 Bob Hinden Changed document writeup
2014-09-09
04 Brian Carpenter New version available: draft-ietf-6man-why64-04.txt
2014-09-04
03 Bob Hinden Document shepherd changed to Robert M. Hinden
2014-09-04
03 Bob Hinden Tag Revised I-D Needed - Issue raised by WG cleared.
2014-09-04
03 Bob Hinden IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2014-08-26
03 Brian Carpenter New version available: draft-ietf-6man-why64-03.txt
2014-08-15
02 Brian Carpenter New version available: draft-ietf-6man-why64-02.txt
2014-08-06
01 Ole Trøan Document shepherd changed to Ole Troan
2014-08-04
01 Ole Trøan Tag Revised I-D Needed - Issue raised by WG set.
2014-07-23
01 Ole Trøan IETF WG state changed to In WG Last Call from WG Document
2014-06-02
01 Ole Trøan Intended Status changed to Informational from None
2014-05-07
01 Brian Carpenter New version available: draft-ietf-6man-why64-01.txt
2014-04-23
00 Ole Trøan This document now replaces draft-carpenter-6man-why64 instead of None
2014-04-11
00 Brian Carpenter New version available: draft-ietf-6man-why64-00.txt