Subject: [BEHAVE] comments on draft-ietf-behave-v6v4-xlate-stateful-07

From: "Dan Wing" <[email-masked]>
Date: Wed, 6 Jan 2010 11:08:27 -0800

My comments on draft-ietf-behave-v6v4-xlate-stateful-07,

The Abstract, title, and per-page titles all say "NAT64", and paraphrasing the
abstract slightly, the abstract says 'NAT64 and DNS64 allow an IPv6-only
client to talk to an IPv4-only server'.  This implies that stateless
NAT64+DNS64 cannot perform that same function; but they can.  

The abstract also neglects to mention "stateful", which is a significant
component of this document; it is, in fact, the main purpose of this document.

To me, this describes the major aspects of stateful NAT64 better; please
consider how the main points below can be integrated into your abstract (only
TCP/UDP/ICMP, unicast, IPv4 address sharing, and that NAT64 can be used in
conjunction with DNS64 and *usually* no changes are required in the apps):

   This document describes stateful NAT64 translation, which allows
   IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, 
   or ICMP.  The public IPv4 address can be shared among several IPv6-only 
   clients.   When the stateful NAT64 is used in conjunction with a DNS64, 
   as described in associated Framework document, no changes are usually 
   required in the IPv6 client or the IPv4 server.

I wouldn't bother mentioning p2p in the abstract because the only other
place it is mentioned is the introduction.  Thus, it feels like too small 
an aspect of the document's purpose to warrent mentioning in the abstract.

Introduction should be made parallel to the main points of the Abstract.

Introduction:

   However, some advanced features such as support for DNSSEC
   validating stub resolvers or support for some IPsec modes, require
   software updates to the IPv6-only hosts.

out of scope for NAT64.

the last paragraph of the introduction, which discusses relationship with
NAT-PT, is out of scope.  If anything, that belongs in the Framework document
or a separate document.  As it is, it's too short to describe what it hopes to
describe.

Section 1.1:

      Because of the
      compliance with the aforementioned requirements, NAT64 is
      compatible with ICE [I-D.ietf-mmusic-ice].

also say "and compatible with other non-IETF-standard NAT traversal
techniques."

Section 1.1, other major features are:

  * IPv4 address sharing   (in fact, I would claim it is *the* major feature
    of stateful NAT64).  The point to make in the text is that IPv4 address
    sharing helps with IPv4 exhaustion.

  * only TCP/UDP/ICMP are supported.

Section 1.2, Overview:

   NAT64 mechanism is implemented in an NAT64 box which has (at least)

It says "box" -- so, it *can't* be implemented in a host?  How about using
"NAT64 function"?

   In order to be able to perform
   IPv6 - IPv4 translation NAT64 requires state, binding an IPv6 address
   and port (hereafter called an IPv6 transport address) to an IPv4
       ^^^^
   address and port (hereafter called an IPv4 transport address).
               ^^^^

should say "TCP/UDP port".  But this immediately makes me wonder how ICMP
is handled, as it doesn't have a port (it has query-id, instead).  So,
really, "port" isn't quite right either.

How about starting by calling it a "transport address" (instead of
mentioning port), and defining "transport address" in the terminology
section.  Then the text would read something like "... binding an
IPv6 transport address (e.g., IPv6 address and TCP port) to an 
IPv4 transport address."

Section 1.2.1, I don't understand the sentence:

   Moreover, because of the IPv4 address scarcity, the usual practice
   for NAT64 is likely to be the mapping of IPv6 transport addresses
   into IPv4 transport addresses, instead of IPv6 addresses into IPv4
   addresses directly, which enable a higher utilization of the limited
   IPv4 address pool.

(what does 'mapping' mean?  And does the 'which' in the last phrase apply to
immediately preceeding phrase??)

   An IPv6 initiator can know or derive in advance the IPv6 address
   representing the IPv4 target and send packets to that address.  

Yes, it could -- via assuming WKP or using wing-behave-learn-prefix.  However,
the most common way, which is what this section is trying to introduce to the
reader, is DNS64.  Why not say, instead:

  Using DNS64, an IPv6 client obtains an IPv6 address that embeds
  the IPv4 address of the IPv4 server, and sends a packet to that
  IPv6 address.

Section 1.2.2:

   2.  H1 sends a packet to H2.  The packet is sent from a source
       transport address of (Y',y) to a destination transport address of
       (Pref64:X:SUFFIX,x), where y and x are ports set by H1.

this is an example, so let's have that packet be a TCP packet, specifically a
TCP SYN.  Maybe even to port 80.  That avoids having to discuss ICMP in this
example.

same section:

       *  The NAT64 includes (T,t) as source transport address in the
          packet and (X,x) as destination transport address in the
          packet.  Note that X is extracted directly from the
          destination IPv6 address of the received IPv6 packet that is
          being translated.

Both X (destination IPv4 address) and x (destination port number) are
extracted from the received IPv6 packet.  Except in the case of ICMP, which I
think you would be best to exclude from this example.

   Hairpinning:  Having a packet do a "U-turn" inside a NAT and come
      back out the same interface as it arrived on.  Hairpinning support
      is important for peer-to-peer applications, as there are cases
      when two different hosts on the same side of a NAT can only
      communicate using sessions that hairpin through the NAT.

Section 3.5 restricts hairpinning to only IPv6-NAT-IPv6 (that is, IPv6 host
through the NAT to another IPv6 host).  You might mention that in the
defintion.

   NAT64:  A device that translates IPv6 packets to IPv4 packets and
      vice-versa.  The NAT64 uses mapping state to perform the
      translation between IPv6 and IPv4 addresses.  The translation
      involves not only the IP header, but also the transport header
      (TCP or UDP).

I suggest, instead, something that mentions 'stateful' and the
TCP/UDP/ICMP limitation in the first sentence, something like:

 "A function that has per-flow state which translates IPv6 packets
  to IPv4 packets and vice-versa, for TCP, UDP, and ICMP.  The per-
  flow state is created when packets are sent from the IPv6 interface
  to the IPv4 interface."

   Session:  A TCP, UDP or ICMP Query session.  In other words, the bi-
      directional flow of packets between two different hosts.  In
      NAT64, typically one host is an IPv4 host, and the other one is an
      IPv6 host.

add, "however, due to hairpinning, both hosts might be IPv6 hosts."

Section 3.1:

      The NAT64 MUST handle fragments, even if the arrive out-of-order,
                                               ^^^
                                               they
      conditioned to the following:

However, I would make the handling of out-of-order fragments its own
separate MUST.

Section 3.2.2, instead of specifying the timeout values ("lifetime is set to 4
min"), please use a mnemonic such as "T" or "SHORTLIFE" or something, and have
a table of suggested values for all timers you are using.  Also, use "minute"
instead of "min" (which can be confused with "minimum").  The table should
include recommended timers for UDP, all TCP states, and ICMP.

Section 3.2.2, "lifetime is set to at least 2 hours and 4 min.", in the table
you need an explanation of where you got that value (which appears to be half
of RFC793's maximum segment lifetime (4.55 hours) plus 4 minutes??).

Section 3.2.2,

   If it is not possible to allocate an appropriate IPv4 transport
   address or create a BIB entry for some reason, then the packet is
   discarded.  The NAT64 MAY send an ICMPv6 Destination Unreachable/
   Address unreachable (Code 3) message.

does not agree with REQ-8 of RFC5508, which says:

  "REQ-8: When a NAT device is unable to establish a NAT Session for a
   new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource
   constraints or administrative restrictions, the NAT device SHOULD
   send an ICMP destination unreachable message, with a code of 13
   (Communication administratively prohibited) to the sender, and drop
   the original packet."

Section 3.2.3, I noticed this ICMP section does not require the outgoing IPv4
address be the same as an existing BIB.  That is, the TCP section and the UDP
section both have a "Rules for allocation of IPv4 transport addresses for
[TCP|UDP]" which contains:
      If there exists some other BIB entry containing S' as the IPv6
      address and mapping it to some IPv4 address T, then use T as the
      IPv4 address.  Otherwise, use any IPv4 address of the IPv4 pool
      assigned to the NAT64 to be used for translation.
however, the ICMP section doesn't have similar wording; instead, the ICMP
section appears to only be trying to keep all ICMP traffic on the same
outgoing IPv4 address with its text that reads:
      Else, the NAT64 searches for a ICMP Query BIB entry that matches
      the (X',I1) pair.  If such entry does not exist, a new entry is
      created with the following data:
I believe we want TCP, UDP, *and* ICMP to use the same public IPv4 address,
yes?

Section 3.2.3, the "i.e." phrases throughout that section need to be put into
parenthesis to make them easier to read.  For example,

OLD:
         The BIB ICMPv6 Query Id is set to I1 i.e. the ICMPv6 Query
         Identifier.
NEW:
         The BIB ICMPv6 Query Id is set to I1 (i.e. the ICMPv6 Query
         Identifier).

Section 3.2.3, 

      The NAT64 sets or resets the timer in the session table entry to
      maximum session lifetime.

should use a mnemonic and reference the table.

Section 3.2.4, which defines the algorithm for translating the
address, seems redundant with draft-ietf-behave-address-format.  What
I mean is I believe draft-ietf-behave-address-format already specifies
the necessary MUSTs for how the address is formulated.  These requirements
for reversibility are not specific to stateful NAT64; they are the same
requirements for stateless translation, too -- for example, the DNS64
used with a [stateless | stateful] translator has to synthesize AAAA
responses with an IPv6 prefix useful to the translator, so the text:

      The same algorithm to create an IPv6 address from an IPv4 address
      MUST be used by:

         The DNS64 to create the IPv6 address to be returned in the
         synthetic AAAA RR from the IPv4 address contained in original A
         RR, and,

is not specific to stateful NAT64.  I believe the rest of Section 3.2.4
is also not specific to stateful NAT64.

Section 3.4 describes what to do when the protocol is UDP, TCP, and ICMP.  It
does not describe what to do when the protocol is something else (e.g., RSVP,
SCTP).  It should.  We should drop it and respond with ICMP destination
unreachable code 13.

Section 3.5 should explain *why* hairpinning might occur:  two IPv6 hosts
might only know about each other's IPv4 transport address.   (This question
has come up on the mailing list at least once.)

Section 4, Security Considerations.  Please create sub-sections.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 12 Jan 2010 19:32:56 +0100

Hi Dan,

thanks for the detailed review

see my replies below.

> an aspect of the document's purpose to warrent mentioning in the abstract.
Ok, i have changed the abstract to your proposed text (i have removed 
the reference to the framework document thought, cause it is not clear 
what framework is and we are not allowed to incldue references.

> Introduction should be made parallel to the main points of the Abstract.
i am not sure what you mean by this.
I have updated the introduction to include your comments below and 
changed NAt64 to stateful nat64.
Not sure if something else is needed.

>    software updates to the IPv6-only hosts.
I have removed this sentence

> or a separate document.  As it is, it's too short to describe what it hopes to
I have removed the whole paragraph

> also say "and compatible with other non-IETF-standard NAT traversal

done
>   * only TCP/UDP/ICMP are supported.

done
> It says "box" -- so, it *can't* be implemented in a host?
mmm, isn't a host a box? I thought it was...

>   How about using

the problem is that it isn't the function that has two interfaces, 
right? But the box running the function has them imho
> really, "port" isn't quite right either.

mmm, i think including TCP/UDP port is the right call.
I mean, after all the main goal of nat64 is to carry data traffic i.e. 
TCP UDP and icmp queries are also supported, but is almost a corner case.
I think it woudl be a mistake to loose clarity in the description to 
cover the icmp case, especially in the overview, which is non normative.
> section.
the problem is that we have added the definition of transport address at 
this point cause people didn't understood what a trnasport address was...
and even if they do, this would still not cover the icmp query case, 
since it  identifier is not a port
>   Then the text would read something like "... binding an

rephrased as:

Moreover, because of the IPv4 address
       scarcity, the usual practice for NAT64 is likely to be the binding of
       IPv6 transport addresses into IPv4 transport addresses, instead of
       IPv6 addresses into IPv4 addresses directly, enabling a higher
       utilization of the limited IPv4 address pool.
>   the IPv4 address of the IPv4 server, and sends a packet to that
ok

> TCP SYN.  Maybe even to port 80.  That avoids having to discuss ICMP in this

done changed to example to a TCP connection
> think you would be best to exclude from this example.
right. added
 The destination port x of the translated
                 packet is the same as the destination port of the 
received IPv6 packet.

> through the NAT to another IPv6 host).  You might mention that in the

not sure why you say that

section 3.5 reads:

   If the destination IP address is an address assigned to the NAT64
   itself (i.e., is one of the IPv4 addresses assigned to the IPv4
   interface, or is covered by the Pref64::/n prefix assigned to the
   IPv6 interface), then the packet is a hairpin packet.  The outgoing
   5-tuple becomes the incoming 5-tuple, and the packet is treated as if
   it was received on the outgoing interface.  Processing of the packet
   continues at step 2.  Filtering and updating binding and session
   information described in Section 3.2

This seems to support IPv6-NAT-IPv6 and also IPv4-NAT-IPv4, right?
what else is missing?
>   flow state is created when packets are sent from the IPv6 interface
I have rephrased as:

         <t hangText="Stateful NAT64:">
        A function that has per-flow state which translates IPv6 packets
          to IPv4 packets and vice-versa, for TCP, UDP, and ICMP.  The 
NAT64 uses binding state to
          perform the translation between IPv6 and IPv4 addresses.

(because of static mappings, the bindings are not only created when 
packets are coursed, but also can be manually created.
> add, "however, due to hairpinning, both hosts might be IPv6 hosts."

mmm, afaiu, hairpinning is supported both for IPv4 hosts and for IPv6 
hosts, so i would need to add that both can be IP6 or both can be IPv6. 
Since the sentence reads typically, i would rather to keep it as it is...
> However, I would make the handling of out-of-order fragments its own
rephrased as:

                <t>The NAT64 MUST handle fragments. In particular, NAT64 
MUST handle fragments arriving out-of-order ,

> include recommended timers for UDP, all TCP states, and ICMP.

done
> of RFC793's maximum segment lifetime (4.55 hours) plus 4 minutes??).
done
>    (Communication administratively prohibited) to the sender, and drop
I am not sure what are objecting to:

If it is the MAYm i have changed it for a SHOULD as per the requirement
If it is to the code 3 instead of the code 13, the problem is that 
ICMPv6 provides clear guidance about when to use each code and in 
particular it reads:

   If the reason for the failure to deliver is lack of a matching entry
   in the forwarding node's routing table, the Code field is set to 0.
   (This error can occur only in nodes that do not hold a "default
   route" in their routing tables.)

   If the reason for the failure to deliver is administrative
   prohibition (e.g., a "firewall filter"), the Code field is set to 1.

   If the reason for the failure to deliver cannot be mapped to any of
   other codes, the Code field is set to 3.  Example of such cases are
   an inability to resolve the IPv6 destination address into a
   corresponding link address, or a link-specific problem of some sort.

and that is why i think code 3 is appropriate... makes sense?

> I believe we want TCP, UDP, *and* ICMP to use the same public IPv4 address,

I think we have clarified this one already

the draft reads:

                If such entry does not exist, a new entry is created 
with the following data:
                <list style="symbols">
                    <t>The BIB IPv6 address is set to X' i.e. the source 
IPv6 address of the IPv6 packet.</t>
                    <t>The BIB ICMPv6 Query Id is set to I1 i.e. the 
ICMPv6 Query Identifier.</t>
                    <t>If there exists another BIB entry containing the 
same IPv6
                         address X' and mapping it to an IPv4 address T, 
then use T as the
                         BIB IPv4 address for this new entry. Otherwise, 
use any IPv4 address assigned to the IPv4
                         interface.</t>
                    <t>As the BIB ICMPv4 Identifier use any available 
value i.e. any identifier value for which
                        no other entry exists with the same (IPv4 
address, ICMPv4 Query Id) pair.</t>
                </list></t>

i understand the third bullet addresses your comment.
>          The BIB ICMPv6 Query Id is set to I1 (i.e. the ICMPv6 Query
done
> should use a mnemonic and reference the table.
i have added the mnemonic, but for the value

> address, seems redundant with draft-ietf-behave-address-format.
not sure about that.
section 3.2.4 defines the requirements for the algorithms used for 
translating the addresses
OTOH, draft-ietf-behave-address-format defines _one_ specific of such 
algorihtms. NAT64 could use other algorithms defined in future documents 
as long as they met the requirements defined in section 3.2.4
>   What
i am not sure we should do that,
I would expect that if there is interest, there will be other documents 
defining how nat64 will handle sctp, dccp, ipsec, and whatever other 
protocols are used.
Including in the nat64 document that a nat64 should drop those packets 
and send an icmp error back doesnt seem to be in line with that. I think 
it would be more appropirate to simply state the the support for other 
prootocols are out of the scope of the document and will be defined 
somewhere else.

> has come up on the mailing list at least once.)

but section 3.5 is the normative description of the nat64, so i don't 
think it is the right place for explaining how hairpinning could occur.
RFC 4787 has a detailed example and definition of hairpinning. I have 
added a reference to that in the definition of hairpinning
> Section 4, Security Considerations.  Please create sub-sections.
done

Regards, marcelo
> -d
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 12 Jan 2010 11:42:56 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
> Sent: Tuesday, January 12, 2010 10:33 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [BEHAVE] comments on 
> draft-ietf-behave-v6v4-xlate-stateful-07
> 
> Hi Dan,
> 

By 'parallel' I mean if the abstract briefly mentions A, B, and C, the
introduction should mention those same things and provide more detail about A,
B, and C.

It sounds like you have done that.

...
> mmm, isn't a host a box? I thought it was...

But mobile phones and laptops are not commonly called 'boxes'.

> right? But the box running the function has them imho

How about 'device'?

> > is handled, as it doesn't have a port (it has query-id, 
> > instead).  So, really, "port" isn't quite right either.
> >
> >   
> 

Then scope it accordingly.  For example, add:

   1.2. Overview

   This section provides a non-normative introduction to the mechanisms
   of NAT64.  This is achieved by describing the NAT64 behavior
   involving a simple setup, that involves a single NAT64 box, a single
   DNS64 box and a simple network topology.  The goal of this
                                            ^
                                            ^
                           For the sake of clarity, only TCP and UDP
                           are described in this overview; the details
                           of ICMP, fragmentation, and other aspects
                           of translation are purposefully avoided in 
                           this overview.

   description is to provide the reader with a general view of NAT64.
   It is not the goal of this section to describe all possible
   configurations nor to provide a normative specification of the NAT64
   behavior.  The normative specification of NAT64 is provided in
   Section 3.

...
>        scarcity, the usual practice for NAT64 is likely to be 
                                          ^^^^^
                      But that will be "stateful NAT64", correct?  

> the binding of

Thanks, makes sense now.

...

> > through the NAT to another IPv6 host).  You might mention 
> > that in the defintion.
> >   
> 

You didn't include the first paragraph of 3.5, which, by my interpretation of
the text, restricts hairpinning to only IPv6-NAT-IPv6.  The entirety of
Section 3.5 says:

   This step handles hairpinning if necessary.  A NAT64 that forwards
   packets originating from an IPv6 address, destined for an IPv4
   address that matches the active mapping for another IPv6 address,
   back to that IPv6 address are defined as as supporting "hairpinning".

Question: do we want or need hairpinning to work for IPv4-NAT-IPv4?  

I'm not even sure how IPv4-NAT-IPv4 hairpinning might work.  Let's say an IPv6
host is talking to an IPv4 host "A", which means there is a mapping in the
stateful NAT64, using the NAT64's public IPv4 address 192.0.2.1 and UDP port
5555.  Now, IPv4 host "B" sends a packet to the NAT64's address 192.0.2.1 and
UDP port 5555.  To me, that packet should be NATted and delivered to the IPv6
host.  How could it get hairpinned to IPv4 host A?

                                                   IPv4 Host A
                                                  /
       IPv6 host-------<IPv6 network>----[NAT64]-<
                                                  \
                                                   IPv4 Host B

If we do need IPv4-NAT-IPv4 hairpinning, the text needs to discuss how such a
session times out (for example, does it need to see traffic to/from the IPv6
side at all?  Or is IPv4-NAT-IPv4 traffic sufficient to keep the mapping
alive?).  What are the security implications of either of those choices, if
any?

> Since the sentence reads typically, i would rather to keep it 

(I'm keeping this in the email reply until we reach a conclusion
about IPv4-NAT-IPv4 hairpinning.)

> and that is why i think code 3 is appropriate... makes sense?

Yes, thanks for pulling up that citation; I confused ICMPv4 with
ICMPv6.

Reading http://tools.ietf.org/html/rfc4443, 

   ICMPv6 Fields:

   Type           1

   Code           0 - No route to destination
                  1 - Communication with destination
                        administratively prohibited
                  2 - Beyond scope of source address
                  3 - Address unreachable
                  4 - Port unreachable
                  5 - Source address failed ingress/egress policy
                  6 - Reject route to destination

I agree Type=1/Code=3 looks good.

I notice draft-ietf-behave-v6v4-xlate doesn't indicate what sort
of ICMPv6 message should be generated if a stateless translator 
can't perform a mapping (e.g., receives a packet from an IPv6
address that isn't mappable).  I will bring that up with the
authors of draft-ietf-behave-v6v4-xlate 

> I think we have clarified this one already

Yes, thanks.

...
> as long as they met the requirements defined in section 3.2.4

Ok.

> prootocols are out of the scope of the document and will be defined 

I saw your proposed text elsewhere, and it looked good.  Thanks.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 13 Jan 2010 12:25:22 +0100

>> right? But the box running the function has them imho

ok, i have changed all the occurrences of box by device
>    behavior.  The normative specification of NAT64 is provided in
added

>                       But that will be "stateful NAT64", correct?  
i have addressed the nat64 vs. stateful nat64 terminology as a reply to 
your other comment.
let's see if the new version has addressed the issue properly

>>>       back out the same interface as it arrived on.  
>>>       
>> Hairpinning support
>>     
right.
I have removed that paragraphs after Bryan review (his comment that this 
was more a description of what hairpinning is rather than normative text)

The current section text reads as follows:

       <section title="Handling Hairpinning">
         <t>If the destination IP address is an address assigned to the 
NAT64
         itself (i.e., is one of the IPv4 addresses assigned to the IPv4
         interface, or is covered by the Pref64::/n prefix assigned to 
the IPv6
         interface), then the packet is a hairpin packet.
          Hairpin packets are processed as follows:
         <list style="symbols">
            <t> The outgoing 5-tuple becomes the incoming 5-tuple, and, </t>
            <t> the packet is treated as if it was received on the 
outgoing interface.</t>
            <t> Processing of the packet continues at step 2 - Filtering 
and updating binding and
         session information described in <xref 
target="sec-session-info"/></t>
        </list></t>
       </section>

>        IPv6 host-------<IPv6 network>----[NAT64]-<
I think i agree that the IPv4-NAT64-IPv4 hairpinning for stateful nat64 
doesn't make much sense.
I mean, the thing is that in a nat64 scenario, an IPv6 host has 3 
representations i.e. its IPv6 address, the transient IPv4 address and 
the IPv6 representation of that transient IPv4 address. In particular, 
the IPv6 node has two valid IPv6 addressed where it is reachable.
The hairpinning occurs because another IPv6 instead of using the "real" 
IPv6 address, it uses the IPv6 representation of the transient IPv4 address.

OTOH, an IPv4 host in a NAT64 setup only has two representations: its 
own IPv4 address and the IPv6 representation of the IPv4 address.
In order for hairpinning to occur, another IPv4 node should try to send 
a packet to the IPv6 representation. Of course that doesn't make sense 
cause the IPv4 host cannot send IPv6 packets. So, i don't think the 
hairpinning is possible in the IPv4 case, since the IPv4 hosts only have 
one IPv4 address assigned to them in a nat64 setup.

In the example above, i don't think this can be called hairpinning cause 
192.0.2.1 is not a representation of Host A, correct?

would that make sense?

If, so i will remove the Pref64 from the text above in the hairpinning 
case... is there something else we shoudl do about this issue?
> alive?).  What are the security implications of either of those choices, if
after this exchange, i am not sure i understnad what ipv4-nay-ipv4 
hairpin would make sense...

>>>   flow state is created when packets are sent from the IPv6 
>>>       
>> interface
>>     
>>>   to the IPv4 interface."
>>>
>>>   
>>>       
>> I have rephrased as:
>>
>>>    Session:  A TCP, UDP or ICMP Query session.  In other 
>>>       
>> words, the bi-
>>     
>>>       NAT64, typically one host is an IPv4 host, and the 
>>>       
>> other one is an
>>     
>>>       IPv6 host.
>>>
i will add that text in the session definition, then

Regards, marcelo

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 13 Jan 2010 10:55:37 -0800

...
> case... is there something else we shoudl do about this issue?

How about this wording:

  If the destination IPv6 address and its embedded IPv4 address 
  are both assigned to the NAT64 itself, then the packet is 
  being sent to another IPv6 host connected to the same
  NAT64.  Such a packet is called a 'hairpin packet'.

I expect during IETF last call and/or IESG review, someone will
ask "how could this possibly be needed!", so a sentence might be 
useful at the beginning of the hairpin section, something akin
to:

  Due to referrals or other reasons, an IPv6 host might only
  know the IPv4 representation of another IPv6 host.  If those
  two IPv6 hosts are connected to the same stateful NAT64, the
  NAT64 needs to support their communication, by supporting 
  hairpinning.  Although there are efforts underway to help hosts 
  be aware of the direct IPv6 path to the other IPv6 host, these 
  efforts are still nascent.

(cite GROBJ if you want, or not.)

> hairpin would make sense...

I think it doesn't, so the text should be explicit that it's
only covering IPv6-NAT64-IPv6.  I believe with the above changes
it is clearer.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 14 Jan 2010 11:25:16 +0100

Dan Wing escribió:
> ...
>   
>>>    This step handles hairpinning if necessary.  A NAT64 
>>>       
>> that forwards
>>     
>>>    back to that IPv6 address are defined as as supporting 
>>>       
>> "hairpinning".
>>     
>>>    IPv6 interface), then the packet is a hairpin packet.  
>>>       
>> The outgoing
>>     
>>>    5-tuple becomes the incoming 5-tuple, and the packet is 
>>>       
>> treated as if
>>     
>>>    it was received on the outgoing interface.  Processing 
>>>       
>> of the packet
>>     
>>> Question: do we want or need hairpinning to work for 
>>>       
>> IPv4-NAT-IPv4?  
>>     
>>> I'm not even sure how IPv4-NAT-IPv4 hairpinning might work. 
>>>       
>>  Let's say an IPv6
>>     
>>> host is talking to an IPv4 host "A", which means there is a 
>>>       
>> mapping in the
>>     
>>> stateful NAT64, using the NAT64's public IPv4 address 
>>>       
>> 192.0.2.1 and UDP port
>>     
>>> 5555.  Now, IPv4 host "B" sends a packet to the NAT64's 
>>>       
>> address 192.0.2.1 and
>>     
>>> UDP port 5555.  To me, that packet should be NATted and 
>>>       
>> delivered to the IPv6
>>     
Integrating your proposed text with previous suggestions from other 
reviewers, the defintion of hairpinning in the termonilogy section reads:

         <t hangText="Hairpinning:">Having a packet do a "U-turn" inside 
a NAT
         and come back out the same interface as it arrived on.
         If the destination IPv6 address and its embedded IPv4 address
         are both assigned to the NAT64 itself, then the packet is
         being sent to another IPv6 host connected to the same
         NAT64.  Such a packet is called a 'hairpin packet'.
         A NAT64 that forwards hairpin packets, back to the IPv6 host 
are defined as
         supporting "hairpinning". Hairpinning
         support is important for peer-to-peer applications, as there are
         cases when two different hosts on the same side of a NAT can only
         communicate using sessions that hairpin through the NAT. More 
detailed
         explanation of hairpinning and examples can be found in <xref
         target="RFC4787"></xref>.  </t>

would that work for you?

Regards, marcelo

>>> If we do need IPv4-NAT-IPv4 hairpinning, the text needs to 
>>>       
>> discuss how such a
>>     
>>> session times out (for example, does it need to see traffic 
>>>       
>> to/from the IPv6
>>     
>>> side at all?  Or is IPv4-NAT-IPv4 traffic sufficient to 
>>>       
>> keep the mapping
>>     
>>> alive?).  What are the security implications of either of 
>>>       
>> those choices, if
>>     
>>> any?
>>>
>>>   
>>>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 15 Jan 2010 07:46:01 -0800

>          target="RFC4787"></xref>.  </t>

RFC4787 is UDP, which implies that hairpinning only occurs with UDP
and that the NAT64 only needs to support UDP.  How about throwing in 
"TCP or UDP" somewhere.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 16 Jan 2010 12:47:23 +0100

> and that the NAT64 only needs to support UDP.  How about throwing in 
added:

 Hairpin packets packets can be either TCP or UDP. More detailed
         explanation of hairpinning and examples for the UDP case can be 
found in <xref
         target="RFC4787"></xref>.
regards, marcelo