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

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Jan 2010 08:26:43 +1300

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

---

From: Alberto García <[email-masked]>
Date: Mon, 11 Jan 2010 17:50:30 +0100

Hi

Thanks for the comments,

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre de
|  Brian E Carpenter
|  Enviado el: domingo, 10 de enero de 2010 20:27
|  Para: [email-masked]
|  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, 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
|  [email-masked]
|  https://www.ietf.org/mailman/listinfo/shim6

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Jan 2010 13:19:03 +1300

Hi Alberto,

On 2010-01-12 05:50, Alberto García wrote:
> 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
> 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.

> will fail, and REAP will recover by switching to a valid path, if it exists.

Correct.

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

> routers (at least) to be part of a single connected source based routing

Yes, very good.

> inferior solution to the others, so I don't think it worth mentioning.

I agree.

> arise for a multipath TCP solution".

Perfect.

Thanks
    Brian

---

From: Alberto García <[email-masked]>
Date: Fri, 15 Jan 2010 12:29:54 +0100

Hi Brian

Just to clarify how to deal with the NAT64 issue you mentioned in the
applicability draft. Do you think this issue would be addressed by
substituting the last sentence of "3.1. Protocol Version (IPv4 vs. IPv6)":

"Besides, in order to be useful, Shim6 IPv4
   support would require NAT traversal mechanisms which are not defined
   yet and that would imply additional complexity (as any other NAT
   traversal mechanism)."

by

"Besides, Shim6 may have additional problems if locators become translated
on the wire. Address translation is more likely to involve IPv4 addresses,
resulting either from IPv4-to-IPv4 address translation (for example, private
IPv4 address into public IPv4 address, and vice versa), or from IPv4-to-IPv6
address translation (for example, as defined by NAT64,
[draft-ietf-behave-v6v4-xlate-stateful-07]). When address translation
occurs, a locator exchanged by Shim6 for a host could not be used to reach
it, either because the translated version of this locator is not known or
because it does not exist the translation state in the translator device.
Support for this situation would require NAT traversal mechanisms which are
not defined yet and that would imply additional complexity (as any other NAT
traversal mechanism)."

Do you think this is correct?

Regards,
Alberto

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

---

From: Brian Carpenter <[email-masked]>
Date: Sat, 16 Jan 2010 11:07:35 +1300

Looks OK to me thanks. (Some minor corrections needed to the English
when this goes to the RFC Editor).

    Brian