OSPFv3 over IPv4 for IPv6 Transition
draft-ietf-ospf-transition-to-ospfv3-12

I have a couple of comments that I want to see addressed before publication; I don't think they raise to a DISCUSS, but are not minor.  …and a couple of nits…

Comments:

1. I think there's an rfc2119 conflict in Section 3.1. (Source Address); the text says: "All OSPFv3 routers on the link SHOULD share the same IPv4 subnet for IPv4 transport to function correctly…Accordingly, an OSPFv3 router implementation MAY support adjacencies with OSPFv3 neighbors on different IPv4 subnets."   I think this text presents a conflict because the support of adjacencies in different IPv4 subnets is optional (MAY), while the "SHOULD" implies a much stronger requirement.   Suggestion: s/SHOULD/should

2. Section 3.3. (Operation over Virtual Links): "…it is RECOMMENDED to use the IP transport matching the address family in OSPF routing domains requiring virtual links."  This sentence is wrong because (as you said in the previous one) "If IPv4 transport, as specified herein, is used for IPv6 address families, virtual links cannot be supported."  IOW, the IP transport for IPv6 AFs MUST be IPv6.  "RECOMMENDED" implies that there may be a case where it is ok not to do it, that that is not the case here.


Nits:

n1. In the Introduction, "…because both IPv4 and IPv6 address families can be advertised using either IPv4 or IPv6", I think you meant "IPv4 or IPv6 transport".

n2. This statement is superfluous because (to me) you're comparing apples and oranges: " Unlike 6to4 encapsulation [RFC3056] that tunnels IPv6 traffic through an IPv4 network".

n2. Section 4. (IPv4-only Use Case) is ok, but it seems out of place.  Maybe put it right after the Introduction, or make it a subsection of it.

Nit: „Further work such as [ipsecospf] would be required to support IPsec protection for OSPFv3 over IPv4 transport.“ -> I guess that should mean OSPFv2 here...?

This was nice work.

I did have one question - I don't think it would be a likely problem, but is it worth pointing out that you're taking OSPFv3 payloads that might have been sized for IPv6, and encapsulating them as IPv4 payloads that might have a smaller MTU?

If you tell me this isn't a problem, I'll believe you, of course, but I needed to ask :-)

section 4: Just checking that I've gotten this right. Is the
following correct? 

If RFC7166 is being used then there is never a need to modify
packets in a way that would break the authentication. In other
words, am I correct that this draft doesn't envisage any middlebox
changing an OSPF packet in between the source (of authentication)
and destination(s)? 

If that is correct, then we're good. 

If that is not correct, then I think more needs to be said in
section 4, as it is not at all clear to me how a source could emit a
packet that a middlebox could modify, without having to share the
symmetric secret used for RFC7166 authentication with that
middlebox, which would be fairly clearly undesirable.