[v6ops] AD Review of draft-ietf-v6ops-transition-comparison

[Warren Kumari <[e-mail]>]

Firstly, thank you very much to the authors and WG for writing this, and
apologies for the delay in reviewing it -- I did the review, but then
forgot to transfer my notes.
I think that it is a very useful document; there are many different
transition technologies to choose from, and it can be really intimidating
for an operator to have to choose which one(s) to deploy.

I do have a number of concerns that I’d like to see addressed before moving
this forward. Many / most of them will be really easy to address, and
getting them done before IETF LC and IESG will make the whole process go
much smoother (and should result in less drama :-) )

Questions / comments / issues:

Section 2.1:
1: “464XLAT is a single/dual translation model, …” - please explain what a
“single” vs “dual” translation model *is*. This is a bit of a common theme
throughout the document - you are using terms which are well known within
the V6 operator world, but your audience is not really IPv6 experts…

2: “Note that we generally do not see state close to the end-user as
equally problematic as state in the middle of the network.”
- Who is this “we” of which you speak? (The authors? The IETF? Operators?)

3: “In this case, the IPv6-only client sends out IPv6 packets, thus CLAT
functions as an IPv6 router and the PLAT performs a stateful NAT64 for
these packets.”
The “thus” is confusing. Perhaps “and”?

4: “Alternatively, one can say that the DNS64 + stateful NAT64 is used to …”
The “the” seems superfluous -> “Alternatively, one can say that DNS64 +
stateful NAT64 is used to …”


Section 2.2:
1: “The AFTR performs encapsulation/decapsulation of the 4in6 traffic and
translates the IPv4 payload to public IPv4 source address using a stateful
NAPT44 function.“
What is “4in6” and “NAPT44”? (yeah, obviously I know, but please add
references / an explanation)

Section 2.3:
1: “... of provisioning each lwB4 with a unique tuple of IPv4 address
unique range of layer-4 ports.“
Unable to parse. I think you are missing “and a” between “address” and
“unique”.

2: “Direct communication between two lwB4s is performed by hair-pinning
traffic through the lwAFTR.”
Very minor issue, but it’s a little hard to figure out what is meant by
“Direct” - if it hairpins through something else, then it feels like it
isn't really “direct” any more. I don’t have any useful suggestions to
offer though (unless you say things about “on the same network” or “that
don’t need translation” or something, but that feels messy)


Section 2.4:
1: “MAP-E uses a stateless algorithm to embed portions of the customer's
allocated IPv4 address (or part of an address with A+P routing) into the
IPv6 prefix delegated to the client.”
Ok, fine, but in Section 2.1 you say “IPv4-embedded IPv6 addresses
[RFC6052] are used for both source and destination addresses.” - how is
this different?

2: “The CE (Customer-Edge) router typically performs stateful
NAPT44[RFC2663] to translate the private IPv4 source addresses and source
ports into an address and port range defined by applying the MAP rule
applied to the delegated IPv6 prefix.”
Too many “applies” (“applying the MAP rule applied”) - perhaps just drop
the second?

Sec 2.5:
1:”A MAP CE typically performs stateful NAPT44 to translate traffic …“
Please expand “CE”. Actually, while writing this I tried to find a good
expansion – the RFC Editor list has “Customer Edge”, but you first use CE
on page 5 ("customer’s CE router”), so perhaps just fix it there and drop
the first “customer’s”?


Sec 3.1:
1: General note: This entire section (“High-level architectures and their
Consequences”) seems to me to do a much better job of explaining what the
document is all about, explains 464 and 6-in4, etc. I’d strongly suggest
moving at least 3.1, 3.2 and 3.3 before Section 2. I realize that this is a
fair bit of work / shuffling, but I’m also fairly sure that someone will
raise it during LC / IESG eval, so probably worth doing now…


Sec 3.4:
1: “ From the 65,535 ports available per IPv4 address, we could even
consider reserving 1,024 ports, in order to allow customers that need EAMT
entries for incoming connections to well-known ports, …“
Please try to find a reference for “well-known ports”. I figured that the
IANA port list would work (
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml)
but it actually calls them “system ports” (“Port numbers are assigned in
various ways, based on three ranges: System Ports (0-1023), …” Maybe just
change to “system ports” instead?

2: “ Further to that, the NAT46 in the CLAT will actually hide the
subscriber LANs port usage …”
“Further to that, “ feels like a fragment, largely because it is a new
paragraph / does not follow on from the previous paragraph. Perhaps just
drop it.


Sec 4.4.1:
1: “For the operator side functionality, some free open-source
implementations exist:”
This will not age well. Perhaps add something about “At the time of
publication…”


Sec 4.4.2:
1: “ Several cellular networks use 464XLAT, whereas we are not aware of any
deployment of the four other technologies …”
Again, who is this “we”?


Section 8:
1: “For all five technologies, the CE device should contain a DNS proxy.”
Erm. I’m quite uncomfortable with this being suggested here. I’d think that
a recommendation like this would need some much wider discussion. I suspect
that many DNS operators would seriously disagree with a suggestion like
this. I suggest you remove it. Even if most CPE *do* include a proxy,
having it recommended in an RFC is another matter entirely.



Please shout LOUDLY once you've had a change to address these, or with any
questions, etc.
W