Last Call Review of draft-ietf-softwire-map-10
review-ietf-softwire-map-10-opsdir-lc-baker-2014-10-02-00

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the operational area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

At this point, I would describe the document as “Mostly Ready” or "Ready with
nits”. I’ll detail my questions as I go through this.

This document, in its words, "describes a mechanism for transporting IPv4
packets across an IPv6 network using IP encapsulation, and a generic mechanism
for mapping between IPv6 addresses and IPv4 addresses and transport layer
ports.” It is not the first such mechanism; examples of such mechanisms include
that of RFC 1933, which describes dual stack deployment and IPv6-in-IPv4
tunneling. It was replaced by RFC 2893, which in addition to those describes
the embedding of IPv4 addresses into IPv6, and a mechanism for automated
tunneling of IPv6 over IPv4. That was in turn replaced by RFC 4213, which falls
back to describing dual stack deployment and configured tunneling of IPv6 over
IPv4. The draft mentions 1933 but not 2893 or 4213. It does go on to mention
6over4 [RFC2529], 6to4 [RFC3056], ISATAP [RFC5214], and 6rd [RFC5969] in the
introduction, and RFC 2473 in section 4. There are also other proposals on the
table.

All of these assume a pervasive IPv4 network into or over which an IPv6 network
is being deployed.

There are additionally 110 RFCs that to one degree or another contemplate
IPv6-only networks. Most of these simply talk about the possibility of such
without thinking very hard about the operational implications of that. If
anything, they tend to assume that there is a pervasive central IPv4 network,
parts of which are likely dual stack, with a periphery that includes some
IPv6-only networks. The structural integrity of the IPv4 network is not
questioned.

Softwire’s MAP architecture, in both the encapsulation and translation
variants, starts from the premise that the structure of the IPv4 network is no
longer pervasive, and that in different places IPv4 may be providing transport
service to IPv6 and in other places IPv6 may be providing transport to IPv4.
When either is used as transport for the other, continuity of the overlaid
network has to be consciously supported or the overlaid network has to route
around the underlay. This draft uses encapsulation as a means by which an
IPv6-only network can interconnect otherwise-separated IPv4-capable networks,
which may be upstream or downstream, and may or may not support IPv6 services.

The questions I had while reading the document follow. In many cases, they turn
around the use of a word, and can be clarified by clarifying that usage.

Section 4 is entitled “Architecture”. It describes a MAP environment as an
IPv6-only domain surrounded by IPv4-capable domains, and has a mapping node
between it and each of those domains that manages the overlay. Downstream
IPv4-capable domains are presumed to have an IPv4 NAPT, which would be
consistent with residential broadband. “MAP”, it says, "supports the
encapsulation mode specified in [RFC2473].” As long as the RFC is, I think that
tells me that MAP supports any of a number of tunneling mechanisms, and either
by routing or manual configuration, directs traffic across those tunnels. It
would have been helpful to me if that statement had been present.

Section 5, “Mapping Algorithm”, leaves me with several questions. What does it
mean for the “basic” or “forwarding” mapping rules to be mandatory or optional?
I think it means that the code MUST implement both, but the configuration MAY
omit the forwarding rule. Were I implementing this, though, I might seriously
ask whether the implementation of forward rules was optional if my target
market didn’t require them. This is probably addressed in 5.2 and 5.3, but
would do well with a sentence here.

Section 5.1 indicates that ports may be aggregated in the same way that
addresses aggregate into prefixes. That is certainly one way to do that. I
think we have some applications that use port ranges; if we do, we will need to
be ably to express port ranges. This is, I think, actually important to fix
before IESG review.

Attachment:

signature.asc

Description:

 Message signed with OpenPGP using GPGMail