IPv4 Service Continuity Prefix
draft-ietf-v6ops-clatip-04

[Ballot comment]
Thanks for addressing Barry's comment on the Security Considerations question.  I'm fine with that just being an operational consideration and that it won't work.

[Ballot comment]
  To avoid conflicts with any other network that may communicate with
  the CLAT or other IPv6 transition solution, a locally unique IPv4
  address must be assigned.

Maybe I'm wrong, but the sentence above seems to contradict the one below.

  It is important
  that a host never enable 2 active IPv4 continuity solutions
  simultaneously in a way that would cause a node to have overlapping
  address from 192.0.0.0/29.

Also, don't you need a MUST and MUST NOT, respectively, in the two paragraphs?

[Ballot comment]
I have no objection to the publication of this document.

Thanks to the shepherd for noting that softwire had seen the I-D. It would have been good to say why that WG decided not to take this on.

[Ballot comment]
I was wondering the same thing as Barry about the caution against overlapping addresses, although I thought for awhile and failed to come up with a scenario in which having multiple solutions configured on the same address would actually create a vulnerability as opposed to just being broken.

[Ballot comment]
Some non-blocking comments:

To the document shepherd: Thanks, Fred, for being clear about the uncertainty of the correct document status for this.  This AD, at least, sees no issue with an Informational RFC "updating" a Standards Track one, and thinks this would be fine as Informational.  That said, I don't object to Standards Track, and one can certainly say that it's specifying the standard for use of 192.0.0.0/29.  So I'll let other ADs argue about this if they want: the status is currently Standards Track, and that's fine with me.

I'll note that the "updates" tag at the top is done wrong (it should be "Updates: 6333 (if approved)", with no brackets and no "RFC").  The RFC Editor will handle that, but if the authors happen to put out a revised I-D for other reasons, they might fix that while they're at it.

I wonder why it's felt that this updates 6333, and that it doesn't update 6877.  It seems to me that the same argument applies to both: you want people implementing either one to be aware that the other might use the same address block, so you want readers of both RFCs to be aware of this change.  This is specifying an address range that 6877 is expected to use.

The Security Considerations say there's nothing to say, but the paragraph right before that says, "It is important that a host never enable 2 active IPv4 continuity solutions simultaneously in a way that would cause a node to have overlapping address from 192.0.0.0/29."  Isn't that a security consideration?

IESG/Author/WG Chairs:

IANA has reviewed  draft-ietf-v6ops-clatip-02.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has questions about the action requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

Upon approval of this document, the IPv4 Special-Purpose Address Registry located at:

http://www.iana.org/assignments/iana-ipv4-special-registry/

will have the entry for 192.0.0.0/29 revised as follows:

existing entry:

192.0.0.0/29 DS-Lite [RFC6333]

revised entry:

192.0.0.0/29 IPv4 Service Continuity Prefix [ RFC-to-be ]

IANA Question -> IANA requests that a completed template ( as per http://tools.ietf.org/html/rfc6890 ) be provided as part of the IANA Considerations section.

IANA Question -> This draft according to the tracker is only updating
RFC 6333. Is RFC6333 to be replaced as the reference or is the new RFC
to be added to the existing RFC6333 as a second reference?

QUESTION -> Please change the URL in the IANA Considerations section:

FROM:
(http://www.iana.org/assignments/iana-
  ipv4-special-registry/iana-ipv4-special-registry.xhtml)

TO:
http://www.iana.org/assignments/iana-ipv4-special-registry

This will ensure the URL will always work and point to the most
current version/extension.

IANA understands that this is the only action required to be completed by IANA upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IPv4 Service Continuity Prefix) to Proposed Standard


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'IPv4 Service Continuity Prefix'
  as Proposed Standard

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-06-10. 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


  DS-Lite, defined in RFC 6333,  directs IANA to reserve 192.0.0.0/29
  for the B4 element.  This memo directs IANA to generalize that
  reservation to include other cases where a non-routed IPv4 interface
  must be numbered as part of an IPv6 transition solution.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-clatip/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-clatip/ballot/


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

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(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?

This draft updates RFC 6333, which is a Proposed Standard, and is informational. That seems strange. We could make it a BCP that updates the proposed standard, which is also strange. The working group, by charter, is limited to producing informational and BCP documents. I'll leave this in the capable hands of the IESG - let us know what status you think it should have.

(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

  DS-Lite, defined in RFC 6333,  directs IANA to reserve 192.0.0.0/29
  for the B4 element.  This memo directs IANA to generalize that
  reservation to include other cases where a non-routed IPv4 interface
  must be numbered as part of an IPv6 transition solution.

Working Group Summary

There was support in the working group for the draft, and little if any dissent.

Document Quality

This is not a protocol; it is advice to implementers of 464xlat that the prefix set aside for use with DS-Lite may also be used by them. Per Lorenzo Colitti, it is implemented in the Android OS, and works.

Personnel

Document Shepherd: Fred Baker
Responsible Area Director: Joel Jaeggli

(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.

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

No. It was reviewed by softwire, which contemplated taking it themselves and didn't. It has been heavily reviewed by the working group. I doubt that it needs review by other parties in the IETF.

(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.

(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.

Yes.

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

None 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? 

The working group as a whole understands it and is OK with it. I wouldn't describe that as a loud clamor, but if anyone was opposed, I'm pretty sure that I would know.

(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.

The draft makes specific reference to the prefix from RFC 6333, which is 192.0.0.0/29. That shows up in idnits. That, however, is fundamental to the document.

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

The document refers to two RFCs: 6333 and 6877. Both are normative, and both are current.

(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?

no

(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.

no

(16) Will publication of this document change the status of any
existing RFCs?

It does not change the status of RFC 6333, but it updates that document in the sense that a prefix 6333 sets apart for a specific use is also made available for another non-conflicting use.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.

The IANA is directed to update the description of an existing registry. The IANA Considerations section conforms to IANA guidelines.