IPv4 Service Continuity Prefix
RFC 7335
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
(Joel Jaeggli; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
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.
(Alia Atlas; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
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.
(Barry Leiba; former steering group member) No Objection
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?
(Benoît Claise; former steering group member) No Objection
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?
(Brian Haberman; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
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.
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
(Ted Lemon; former steering group member) No Objection