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

Hi

Thanks for the comments,

My understanding of this scenario is as follows: 
In Shim6, the scenario could be

    A1                           B1    
A ---------------- IPv6 ----------- B
    |                               | B2
    |       --------- A2            |
     -IPv6--| NAT64 |------IPv4-----
            ---------

Consider stateful operation (draft-ietf-behave-v6v4-xlate-stateful-07). A
and B establish a communication using IPv6 addresses A1 and B1 (i.e. using
their IPv6 addresses, the only way in which some kind of security can be
provided without protocol changes). B has an additional address B2, which is
IPv4. This address is included as a locator in the shim6 exchange. The
problem of using this locator B as a locator for Shim6 is that A knows how
to build the 'IPv4 Embedded IPv6 addresses' for B, but B does not know which
is the IPv4 address A2 corresponding to A. A2 may even not exist if that
path has not been used; and if A2 existed in the NAT, its state can be
removed by the NAT if no packets are exchanged through the path for sometime
(as Shim6 would do if A1 and B1 are used initially for data exchange).
Additionally, A does not know A2, so it is unable to tell to B using Shim6.
Consequently, it seems that if A is using NAT64 to communicate with IPv4,
IPv4 locators will not be available for Shim6 communication. Host A can know
that is in a NAT64ed domain, and should not use B2 as locator. B does not
know about the problem, but if it tries to use the path <A1, B2>, this path
will fail, and REAP will recover by switching to a valid path, if it exists.

For stateless operation, A could be configured to inform B (in the Shim6
locator exchange, between A1 and B1) about its (static) IPv4 address A2. A
is also able to convert the B2 (IPv4) address received in the Shim6 locator
exchange into its corresponding 'IPv4 Embedded IPv6 addresses'. Therefore,
it seems that in this case the path <A1,B2> can be used for communication.

Do you think this is reasonable? Am I missing something?

|  
|  > 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.

I suppose you refer to "Host-Centric IPv6 Multihoming",
draft-huitema-multi6-hosts-03. 
I agree this should be explained in more detail. With this draft as input,
the paragraph you mention could be substituted by the following text:

"One solution to this problem is to make the providers aware of the
alternative prefixes that can be used by a multihomed site, so that ingress
filtering would not be applied to packets with source addresses belonging to
these prefixes. This may be possible in some cases, but it cannot be assumed
as the general case.

[RFC3704] proposes that non-PI addresses should ensure that each packet is
delivered to the provider related with the prefix of its source address.  To
deliver packets to the appropriate outgoing ISP, some routers of the site
must consider source addresses in their forwarding decisions, in addition to
usual destination-based forwarding. These routers maintain as many parallel
routing tables as valid source prefixes are, and choose a route that is a
function of both the source and the destination address. The way these
routing tables are populated is out of the scope of this document. 
As proposed in [draft-huitema-multi6-hosts-03], it is required for site exit
routers (at least) to be part of a single connected source based routing
domain: 

                 Multiple site exits
                 |     |     |     |
            -----+-----+-----+-----+-----
           (                             )
           ( Source based routing domain )
           (                             )
            ----+----+----+----+----+----
           (                             )
           (   Generic routing domain    )
           (                             )
            -----------------------------
In this way, packets arriving to this connected source based routing domain
would be delivered to the appropriate exit router. 
Some particular cases of this generic deployment scenario are
-	a single exit router, in which the router chooses the exit provider
according to the source address of the packet to be forwarded
-	a site in which all routers perform source address based forwarding
-	a site in which only site-exit routers perform source address based
forwarding, and these site-exit routers are connected through point-to-point
tunnels, so that packets can be tunneled to the appropriate exit router
according to its source address."

The draft from Huitema analyses other approaches to solve this problem,
which I think it is not worth to consider for Shim6 (and therefore would not
appear in the applicability document):
- ask hosts to pick "the right" source address, by pushing by different ways
information about the appropriate source addresses to be used to the host.
One way is by means of ICMP error messages (which is implicit in the last
paragraph of the applicability draft: "If any notification is received from
the router dropping the packets ..." ). The "host centric" draft also
suggests the use of a modified redirect message that informs the host about
the appropriate exit router for a given source address prefix, and requires
the host to tunnel the packet to the appropriate exit router. I think this
is too far from Shim6 philosophy, and uses too many unspecified components,
that it is not worth mentioning.
- source address rewriting in routers: this is considered in the draft as an
inferior solution to the others, so I don't think it worth mentioning.

What do you think?

|  
|  ...
|  >    ...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.

Sure, I include this.

|  
|  > 7.3.  Shim6 and SCTP
|  
|  Also mention that the same issues arise for multipath TCP.

Since there is no specification of multipath TCP (yet), I would just say at
the end of the section that "The issues described here for SCTP may also
arise for a multipath TCP solution".
Do you think this is ok?

|  
|  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.
|  

Sure, 

Alberto

|      Brian
|  _______________________________________________
|  shim6 mailing list
|  shim6@ietf.org
|  https://www.ietf.org/mailman/listinfo/shim6