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

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