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

[Brian Carpenter <[e-mail]>]

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

    Brian

2010/1/16 Alberto García <[e-mail]>:
> 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:[e-mail]]
> |  Enviado el: jueves, 14 de enero de 2010 1:19
> |  Para: Alberto García
> |  CC: [e-mail]
> |  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: [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?
> |  >
>
>
>