OSPFv3 over IPv4 for IPv6 Transition
RFC 7949

Note: This ballot was opened for revision 09 and is now closed.

(Jari Arkko) Yes

Comment (2016-06-29 for -11)
No email
send info
I support this document going forward.

However, in Section 4 it says:

   Consequently, an OSPFv3 packet
   transported within an IPv4 packet requires IPsec to provide
   authentication and confidentiality.  Further work such as [ipsecospf]
   would be required to support IPsec protection for OSPFv3 over IPv4
   transport.

And I had trouble understanding what you meant by this, exactly. IPsec is required, but is not currently completely enough defined for OSPF to make this possible? If so, I'd suggest using the words:

   Consequently, an OSPFv3 packet
   transported within an IPv4 packet requires IPsec to provide
   authentication and confidentiality.  However,  further work such as [ipsecospf]
   would be required to support IPsec protection for OSPFv3 over IPv4
   transport.

But maybe I am misunderstanding what was meant here.

(Alia Atlas) Yes

Suresh Krishnan (was Discuss) Yes

Comment (2016-06-29 for -11)
No email
send info
I do think this is a good mechanism to transition from IPv4-only OSPFv2 to dual-stack capable OSPFv3. Thanks for quickly addressing the issues in my DISCUSS.

Deborah Brungard No Objection

(Ben Campbell) No Objection

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

Comment (2016-06-25 for -09)
No email
send info
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 :-)

(Stephen Farrell) No Objection

Comment (2016-06-29 for -10)
No email
send info

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.

(Joel Jaeggli) No Objection

Mirja Kühlewind No Objection

Comment (2016-06-28 for -09)
No email
send info
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...?

Alexey Melnikov No Objection

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection

Comment (2016-06-27 for -09)
No email
send info
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.