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

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

Hi Alberto,

On 2010-01-12 05:50, Alberto García wrote:
> Hi
> 
> Thanks for the comments,
> 
> |  -----Mensaje original-----
> |  De: [e-mail] [mailto:[e-mail]] En nombre de
> |  Brian E Carpenter
> |  Enviado el: domingo, 10 de enero de 2010 20:27
> |  Para: [e-mail]
> |  Asunto: Re: [shim6] I-D Action:draft-ietf-shim6-applicability-04.txt
> |  
> |  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.
> 
> 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, 

Actually not, in case that the DNS64 magic is done in a separate server,
because then host A does not know the NAT64 PREFIX. But in the case that
the host does know the PREFIX, this would be theoretically possible.

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

Correct

> Host A can know

I'm not sure that is true. If it is a pure IPv6-only host with no DNS64
included, it will not 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.

Correct.

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

I guess so. I'm not sure it is realistic, but it seems possible.

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

Yes, very good.

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

I agree.

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

Perfect.

Thanks
    Brian
> 
> |  
> |  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
> |  [e-mail]
> |  https://www.ietf.org/mailman/listinfo/shim6
> 
>