Re: [shim6] I-D Action:draft-ietf-shim6-applicability-04.txt

[Brian E Carpenter <[e-mail]>]

Hi,

I finally got around to this draft. Substantive points first, then
a couple of nits at the end.

> 3.1.  Protocol Version (IPv4 vs. IPv6)

Maybe this section should mention interaction with NAT64 synthetic
IPv6 addresses.

> 4.  Shim6 and Ingress Filtering
...
>    [RFC3704] proposes that non-PI addresses should ensure that each
>    packet should be delivered to the provider related with the prefix of
>    its source address.  To deliver packets to the appropriate outgoing
>    ISP, forwarding decisions must consider source addresses, in addition
>    to usual destination-based forwarding.  Tunneling may be used in the
>    customer network to reduce the number of routers in which forwarding
>    have to take source address into account.

I found this ('must consider' ... 'may be used') too vague to be useful.
I seem to remember an early draft by Christian Huitema about egress router
selection with more precise content. In any case this is an important topic
for shim6 deployment, so it surely needs to be more precise.

...
>    ...Note that even if
>    such notification is not received, or not processed by the Shim6
>    layer, defective ingress filtering configuration will be treated as a
>    communication failure, and Shim6 re-homing would finally select a
>    working path in which packets are not filtered, if this path exists.

This is a very good point. It might be worth saying explicitly that REAP
is a very powerful technique for end to end resilience.

> 7.3.  Shim6 and SCTP

Also mention that the same issues arise for multipath TCP.

Nits:

In Introduction:

>  In IPv4, site multihoming is achieved by injecting into introducing

Delete 'introducing'.

>    the DFZ.  Site multihoming for sites without PI addresses is achieved

Define 'PI' here instead of later.

    Brian