Hi Juliusz, Warren, and Toke, 

Thank you for the effort put into this document. This is useful piece of work, hence my YES.

Thanks Thomas Graf for the OPSDIR review and the authors for engaging. I think that proving the informative examples provided (IPFIX, …) by Thomas good additions to the document.

Please find below some comments: 

# From where I sit, I think that the forwarding behavior (and ICMP part, in particular) is the main technical contribution, not much the narrative part about routing.

# It is about forwarding, not routing

There are several places in the document that mix routing and forwarding. For example,

OLD: that uses IPv6 next-hop addresses for routing IPv4 packets…
NEW: that uses IPv6 next-hop addresses for forwarding IPv4 packets…

OLD: When a packet is routed according to a given routing table
NEW: When a packet is forwarded according to a given routing table

OLD: preventing an IPv6 packet from being routed through a next
NEW: preventing an IPv6 packet from being forwarded through a next

OLD: routing makes it easy to route IPv4 traffic across interfaces 
NEW: routing makes it easy to forward IPv4 traffic across interfaces 

And several other places. Please check all uses through the document. I trust the responsible AD to help with that check.

# I found it odd that we don’t have any mention of FIBs. Please refer, for example, to RFC1812 about how it reasons for selecting next-hop

RFC1812 has also the following, which can be imported here or referred to:

   Forwarding Information Base (FIB)
        The table containing the information necessary to forward IP
        Datagrams, in this document, is called the Forwarding
        Information Base.  At minimum, this contains the interface
        identifier and next hop information for each reachable
        destination network prefix.

# Manual configuration argument is marginal, IMO: Automation is in place in many operations to handle such provisioning

CURRENT:
   assigned IP addresses of either family, which significantly reduces
   the amount of manual configuration required.

# Independent of routing protocols

CURRENT:
   This document, on the other hand, discusses the
   concept of v4-via-v6 routes independently of any specific routing
   protocol, 

The statement is correct, but I think that this can be even expanded to say that the forwarding behavior described in the document does not even assume or require that a dynamic routing protocol is in place.

# Restrictive assumption: forwarders can be deployed without routing engines (e.g., centralized routing)

CURRENT:
   The forwarding plane is the part of the routing implementation that
   is executed for every forwarded packet.  

Statements such as the above assume that there is co-location of routing and forwarding engines for the mechanism to work. I don’t this is required. Is that on purpose? If so, why?

# Compliant with RFC1812

OLD:
   The forwarding plane is the part of the routing implementation that
   is executed for every forwarded packet. 

The packet may or may not be forwarded as a result of the forwarding process.

I appreciate this is being picky, but RFC1812 says: 

   Forwarding
        Forwarding is the process a router goes through for each packet
        received by the router.  The packet may be consumed by the
        router, it may be output on one or more interfaces of the
        router, or both.  Forwarding includes the process of deciding
        what to do with the packet as well as queuing it up for
        (possible) output or internal consumption.

I suggest:

NEW:
   The forwarding plane is the part of the routing implementation that
   is executed for every packet to be forwarded.


# Section 3.3: I would also add centralized routing + programmatic means to populate the FIBs 

# I don’t think that we need to the first 2 paragraphs in Section 4.

# Same address

CURRENT:
   For these reasons, even if a router performs v4-via-v6 routing on all
   interfaces, it MAY be assigned one or more IPv4 addresses.

RFC6791 which uses such IPv4 addresses but for a distinct purpose. That RFC includes the following reco:

   If a pool of public IPv4 addresses is configured on the translator,
   it is RECOMMENDED to randomly select the IPv4 source address from the
   pool.  Random selection reduces the probability that two ICMP
   messages elicited by the same TRACEROUTE might specify the same
   source address and, therefore, erroneously present the appearance of
   a routing loop.

Should we have a similar one here when more IPv4 addresses are configured?

# Accelerate the deployment of IPv6: Speculative

CURRENT:
   Since it
   promises IPv4 routing essentially "for free" once IPv6 addressing has
   been set up, it has the potential to slightly accelerate the
   deployment of IPv6.

The “accelerate the IPv6 deployment” is operationally more subtle than. To be balanced, as a popular tool that is widely used is 6PE..depends on IPv4.

I think that the point about you made in the previous sentence about dual stack is sufficient. I think that we can simply delete the sentence about accelerating deployment as that is speculative.

# More Operational Considerations

Please consider some brief text for need to have means for routers to expose and for operator to retrieve the capabilities of underlying routers with regards to v4-via-v6 forwarding. This is helpful for operator to maintain a network view of its networks, especilally when bootstrapping new nodes.

Cheers,
Med