Routing for IPv4-Embedded IPv6 Packets
draft-ietf-ospf-ipv4-embedded-ipv6-routing-14

I have only a couple of non-blocking editorial comments:

I honestly had a hard time parsing the abstract.  May I suggest replacing the abstract with what is basically the first paragraph of the Introduction?:

OLD
   This document describes routing packets destined to IPv4-embedded
   IPv6 addresses across an IPv6 core using OSPFv3 with a separate
   routing table.

NEW
   This document describes a routing scenario where IPv4 packets are
   transported over an IPv6 network, based on RFCs 6145 and 6052,
   along with a separate OSPFv3 routing table for IPv4-embedded IPv6
   routes in the IPv6 network.

END

-- Section 1.1 --

   This document focuses on an engineering
   technique which aims to separate the routing table dedicated to
   IPv4-embedded IPv6 destinations from native IPv6 ones.

The "from native IPv6 ones" lacks a reasonable antecedent.  I think you mean this, yes?:

NEW
   This document specifies an engineering
   technique that separates the routing table dedicated to
   IPv4-embedded IPv6 destinations from the routing table used
   for native IPv6 destinations.
END

- Maintaining a separate routing table for IPv4-embedded IPv6 routes
   optimizes IPv4 packets forwarding.
Can you expand on why?

-

  In an IPv6 network, in order to maintain a separate IPv6 routing
   table that contains routes for IPv4-embedded IPv6 destinations only,
   OSPFv3 needs to use the mechanism defined either in [RFC5838] or in
   [I-D.ietf-ospf-mt-ospfv3] with the required configuration, as
   described in Section 3.3 and Section 3.4, respectively.

It looks to me that [I-D.ietf-ospf-mt-ospfv3] should be normative, like RFC 5838
See another sentence:

    and
    if the default OSPFv3 instance is used instead, configuration is
    accomplished according to [I-D.ietf-ospf-mt-ospfv3], as described in
    Section 3.4.

However, [I-D.ietf-ospf-mt-ospfv3] last updated is 2007
Is there an issue with this draft?

- 
   It is assumed that the IPv6 network that is inter-connected with IPv4
   networks in this document is under one administration and as such, an
   OSPFv3 instance ID (IID) is allocated locally and used for OSPFv3
   operation dedicated to unicast IPv4-embedded IPv6 routing in an IPv6
   network.  This IID is configured on OSPFv3 router interfaces that
   participate in the IPv4-embedded IPv6 topology.

Instance ID is per interface, if I'm not mistaken.
So which interface have this interface ID configured: IPv4 facing and/or IPv6 facing?

- 
4. IP Packets Translation


   When transporting IPv4 packets across an IPv6 network with the
   mechanism described above

There are 2 mechanisms: 3.3 and 3.4
So I guess: 
   When transporting IPv4 packets across an IPv6 network with one of the two
   mechanisms described above (section 3.3 and 3.4)



-
OLD
1.  On an AFXLBR, if an IPv4 packet that is received on an interface
       connecting to an IPv4 client network with a destination IPv4
       address belonging to another IPv4 client network, the header of
       the packet is translated to the corresponding IPv6 header as
       described in Section 4, and the packet is then forwarded to the
       destination AFXLBR that advertised the IPv4-embedded IPv6 address
       into the IPv6 network.

NEW
1.  On an AFXLBR, if an IPv4 packet that is received on an interface
       connecting to an IPv4 segregated client network with a destination IPv4
       address belonging to another IPv4 client network, the header of
       the packet is translated to the corresponding IPv6 header as
       described in Section 4, and the packet is then forwarded to the
       destination AFXLBR that advertised the IPv4-embedded IPv6 address
       into the IPv6 network.

Thank you for this work, and thanks to Ben Campbell for the Gen-ART review.

> AFXLBR (Address Family Translation Border Router) is defined in this document.

Nice acronym! Are there any pronunciation guidelines? :-)

Stephen beat me to it.  I thought the whole point of RFC 6506 was that nobody did IPsec for OSPF.

1.1, pedantic nit: OPEX might not be understood by some
readers

1.2, slightly less pedantic nit: "The P routers" isn't a
common term. While it is defined in 5565 it might be no harm
to also say here you mean the internal routers. (I had to go
look.)

11, 3rd para, is that "must" meant as a 2119 MUST? It looks
like it ought be.

11, 4th para, s/currently//

11, why no mention of RFC 6506? Seems like its as relevant as
IPsec maybe.

I'm probably missing something here, but the document doesn't mention the possibility of an MTU issue when a maximally large IPv4 packet is translated into an IPv6 packet: the larger IPv6 header would bump the packet over the MTU size.   Has this been addressed, and I just missed it?