Subject: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-stateful-03.txt

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Sat, 12 Dec 2009 23:46:46 -0800

General comments:
------------------

- What is the requirement for the different tables that the document
presents? 3 BIB tables, 3 session tables etc? Is it a MUST for NAT64 to
have all these tables? If so why?

- Requirement on state tracking. MUST, SHOULD RECOMMEND? Specific
comments on state tracking below.

- Confusing 3-tuple and 5-tuple usage and definition. Specific comments
below.

- There is no recommendation for BIB entry timeouts, is there one
required? RFC4966 lists this as one of the drawbacks for NAT-PT. 

- RFC4966 is mentioned in Section 1 and it is mentioned that a number of
features have been added to overcome the reasons of deprecation of
NAT-PT. I wonder if there should be a section discussing what has been
overcome and how. Because I still see a number of issues discussed in
RFC 4966 applies to this document as well - like ALGs, Binding state
decay, Dos attacks, Loss of information through incompatible semantics
(actually applies to stateless) etc. 

Specific comments.
-------------------

Section 1.1 2nd bullet - TCP [RFC4787] should be TCP[RFC5382]

Section 1.2

NAT64 mechanism is implemented in an NAT64 box which has two interfaces
should be

NAT64 mechanism is implemented in an NAT64 box which has atleast two
interfaces

Section 1.2.1

Paragraph starting "NAT64 creates the required mappings..."

It is a little confusing as it implies a IPv6 address pool is to be
provisioned, but rather a global prefix can used to
algorithmically/statically map the IPv4 addresses into IPv6 addresses. I
would suggest that you use the terminology of algorithmically extracting
the IPv4 address and algorithimically adding the prefix to form the v6
address.

Section 1.2.1

Paragraph starting "Because of the dynamic nature.." last line.

"For this reason NAT64 supports only communications initiated from the
IPv6 side."

Not entirely true, it should be "supports only dynamically initated
communications from the ipv6 side".

Section 1.2.2

Change the title of this section to be more meaningful than
"Walkthrough".

Section 1.2.3

I don't understand this

"Filtering on the IPv6 interface is not supported, as mappings are only
created by packets traveling in the IPv6 --> IPv4 direction."

Can you explain why one cannot filter on ipv6 interface?

Section 2

3-Tuple & 5-tuple.

Kind of confused here, in case of ICMP protocol is not a tuple and in
case of TCP/UDP protocol is a tuple, why is that?

There are two things that the tuple(s) are used for in this document.

1. To extract the required information from the packet.

2. To do a search in the database.

For 1, you need to extract 5-tuple for TCP/UDP(Proto, Src address &
port, Dst address & Port)

4 tuple for ICMP (Proto, Srcaddr, Dstaddr & ICMP ID.

For doing a search and add/update/delete, since you have separate
databases for TCP/UDP/ICMP, the search is based on 4 tuple for TCP/UDP
and 3-tuple for ICMP. So I don't see why the 5-tuple searches mentioned
in the later sections are required. 

Section 3.2

Paragraph 2 "Irrespective ..." does this apply only to stateful NAT64
and not stateless?

Section 3.2.1

Incoming IPv6 packet processing.

Why should the search be based on the 5-tuple, since it is UDP session
table the search is based on the 4-tuple of (SrcIP, DstIP, SrcPort,
DstPort).

Same comment on IPv4 packet processing.

Section 3.2.2 TCP handling.

Lifetime: is a timer that tracks the remaining lifetime of the UDP

Should be TCP above.

Section 3.2.2 TCP states.

What is the purpose of this section, does this document requires all
NAT64 devices to track the sessions with the described state machine? Is
it a MUST, SHOULD, MAY, recommend?

Section 3.2.2
Paragraph starting "After bootstrapping...."

What does it mean all TCP sessions are in closed state? Where is this
tracked?
The state of the TCP session is tracked within the TCP session table
entry and state tracking starts when the entry is created and stops when
the entry is destroyed. So what is this CLOSED state and where is it
tracked? This is very unclear and confusing.

Section 3.2.2 

"The state of the session is moved to V6 SYN RCV". Again where ? The
text for the actual session creation is below this text and until the
session is created where does this state hang off of? 

Section 3.2.2

s/If such entry does not exists/If such an entry does not exist

Section 3.2.2 
"If the lifetime expires, the session table entry is deleted and the
state is moved to CLOSED."

Same comment as above, where is the state stored for this session? 

I will not repeat these comments in the subsequent text in the same
section but this needs some serious explanation and clarifying. 

Section 3.2.3

For port allocation, the text says if the port is even an even port must
be allocated and same for odd. What if there are no even ports to
allocate but there are odd ports, should the packet be dropped or
allocated a odd port. I understand some application require that the
port parity to be maintained but majority of the apps don't care. So
making this a recommendation on the best effort basis is ok but making
it a mandatory requirement sounds unreasonable. Note RFC 4787 recommends
this behavior but this text mandates it.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 14 Dec 2009 00:27:49 +0100

Hi,

thanks for the review

see replies below...

> General comments:
I will try to address some of these here and other i will leave for the 
details comments below

> have all these tables? If so why?
The tables contain the information needed for the NAT64 to work.
I don't think you can make a NAT64 work with less information.
Do you think some of the information stored in the tables is not needed? 
which one?
I would be glad to reduce the state needed by the NAT64, but i fail to 
see what can de dropped.

> comments on state tracking below.
Not clear to me at this point what you mean, will see specific comment below

> - Confusing 3-tuple and 5-tuple usage and definition. Specific comments
Not clear to me at this point what you mean, will see specific comment below

> required? RFC4966 lists this as one of the drawbacks for NAT-PT. 
the behave requirements require to use of timeouts, but since we also 
have endpoint independets mappings, we need to track each session that 
is being used by each endpoint. In order to do that the proposed 
approach is to have timers in the session table entries. SO as long as 
there is at least one session table associated to a BIB entry, the BIB 
entry is preserved, When all session table entries associated to a BIB 
entry are deleted, the BIB entry is deleted.
So, While the BIN entries do have an explicit timer, they are bound to 
the timers of the corresponding session table entries, so they do have a 
timer expiration.

> overcome and how.

Right, we could try to do this, if people find it important. Another 
thing that would be also interesting would be to explain how the NAT64 
complies with the behave requirements for UDP, TCP and ICMP.

Both of these excersises would be good to have in the document as 
appendixes.

We should discuss this in the interim

>  Because I still see a number of issues discussed in
fixed

> NAT64 mechanism is implemented in an NAT64 box which has atleast two
ok

> the IPv4 address and algorithimically adding the prefix to form the v6
Right, i have rephrased the paragraph as:

       <t>The IPv6 address pool is an IPv6 prefix assigned to the 
translator
       itself (hereafter called Pref64::/n). Due to the abundance of 
IPv6 address space,
       it is possible to assign an Pref64::/n that is equal or even 
bigger than the whole IPv4 address space. This allows
       each IPv4 address to be mapped into a different IPv6 address by 
simply
       concatenating the Pref64::/n with the IPv4 address being mapped 
and a suffix (i.e. an IPv4 address X is
       mapped into the IPv6 address Pref64:X:SUFFIX). The provisioning 
of the Pref64::/n is
        discussed at length in <xref 
target="I-D.ietf-behave-address-format" /> </t>

> communications from the ipv6 side".
right, i have removed that sentence

> Change the title of this section to be more meaningful than
I have changed the title to NAT64 behaviour walkthrough

> Can you explain why one cannot filter on ipv6 interface?
good question
NAT64 supports dynamically initiated connections only from the IPv6 
side. So filtering on the IPv6 side seems some how orthogonal to the NAT 
behaviour. I mean you could do that, but you wouldn't be using NAT state 
in order to do so, i think.
OTOH, filtering in the IPv4 interface is different. Since NAT64 cannot 
support communications iniitated in the IPv4 side, when there is a hole 
in the NAT opened by an IPv6 connection and because we are doing 
endpoint independent mappings, we end up with the question on whehter we 
do accept this new communication that has been initiated from the IPv4 
side or not (keep in mind that this is possible only because there is a 
hole open and would not be possible in other case)

So, while the NAT could filter in the IPv6 interface, this seems to be 
orthogonal to the NAT behaviour, but filtering in the IPv4 interface i 
tightly couple to the nat64 state, hence need to be specified.

In any case, i have rephrased the previous sentence to

      Filtering of incoming IPv6 packets is not described in this 
specification.

in order to make it clearer that is not that is not supported, but that 
is not specified here.
> case of TCP/UDP protocol is a tuple, why is that?
mmm, not sure what do you mean here.
In the terminology section it reads:

   3-Tuple:  The tuple (source IP address, destination IP address, Query
      Identifier).  A 3-tuple uniquely identifies an ICMP Query session.
      When an ICMP Query session flows through a NAT64, each session has
      two different 3-tuples: one with IPv4 addresses and one with IPv6
      addresses.

   5-Tuple:  The tuple (source IP address, source port, destination IP
      address, destination port, transport protocol).  A 5-tuple
      uniquely identifies a UDP/TCP session.  When a UDP/TCP session
      flows through a NAT64, each session has two different 5-tuples:
      one with IPv4 addresses and one with IPv6 addresses.

So, the 3-tuple refers to the ICMP case. Not sure how to reword the 
document to make this more clear.

> in the later sections are required. 
mmm, i see what you mean.
OTOH, you could think that you actually search using the 5-tuple, since 
the protocol value in the 5-tupel determines which table (UDP or TCP) 
you need to search.
We could use a 4-tuple for the 2 case, and we would need to define what 
the 4-tuple is and how it relates to the 5-tuple. IMHO, this would 
render the document less clear, but we can discuss further it you want.

> Paragraph 2 "Irrespective ..." does this apply only to stateful NAT64
not sure if it applies to the stateless, it certainly applies to the 
statefull translator, agree?

> Same comment on IPv4 packet processing.
right, see comment above

> Lifetime: is a timer that tracks the remaining lifetime of the UDP
fixed

> it a MUST, SHOULD, MAY, recommend?
This is similar to the the TCP spec. It does have a state machine, you 
can implement it in this way, you could do it in a different way as long 
as the external behaviour is the same.

This is captured in the draft in the following text:

       <t>This breakdown of the NAT64 behavior into processing steps is done
       for ease of presentation. A NAT64 MAY perform the steps in a 
different
       order, or MAY perform different steps, as long as the externally
       visible outcome is the same.</t>

> What does it mean all TCP sessions are in closed state? Where is this
Again, this is similar to the TCP CLOSED state

The closed state is somehow special, cause it means that there is no 
state for the particular connection. I have tried to make this clearer 
in the document by adding the following description:

                    <t>CLOSED: Analogous to <xref 
target="RFC0793"></xref>, CLOSED is a fictional
                      because it represents the state when there is no 
state for this particular 5-tuple, and therefore,
                      no connection.</t>

> the entry is destroyed. 
mmm, i don't think you can keep track of all the state information using 
only the information stored in the session table. In order to keep track 
of the state informtation, you will likely have to keep track to the 
state information in addition to that information in the tables.

> So what is this CLOSED state and where is it
i hope this clarified with the text above.

> session is created where does this state hang off of? 
I have moved the order to the sentence, so that first the session entry 
is created and then the state is moved to V6 SYN RCV, would that help?

> s/If such entry does not exists/If such an entry does not exist
fixed

> section but this needs some serious explanation and clarifying. 
I have made many changes aiming to clarify this in the 04 version. Could 
you check it and see if it clearer now?

> this behavior but this text mandates it.
Right, i have changed this to a should.

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

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Sun, 13 Dec 2009 19:36:32 -0800

Hi Marcelo,
Thanks for the response, please see inline for [Senthil] 

-----Original Message-----
From: marcelo bagnulo braun [mailto:[email-masked]] 
Sent: Sunday, December 13, 2009 6:28 PM
To: Senthil Sivakumar (ssenthil)
Cc: [email-masked]
Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-stateful-03.txt

Hi,

thanks for the review

see replies below...

> General comments:
I will try to address some of these here and other i will leave for the details comments below

> presents? 3 BIB tables, 3 session tables etc? Is it a MUST for NAT64 
> to have all these tables? If so why?
>   
The tables contain the information needed for the NAT64 to work.
I don't think you can make a NAT64 work with less information.
Do you think some of the information stored in the tables is not needed? 
which one?
I would be glad to reduce the state needed by the NAT64, but i fail to see what can de dropped.

[Senthil] My question was more in the lines of must every NAT64 device implement these 3 BIB tables  and 3 Session tables. For example, you could achieve the same with 1 BIB table and 1 session table for TCP/UDP/ICMP. One could do it with 2 or 3 too. It depends on the implementation needs and constraints. I am wondering why do we specify 3 tables in the document. Instead we could refer to these as logical tables and leave it up to the implementation as to however one choose to implement as long as the behavior is the same.

> - Confusing 3-tuple and 5-tuple usage and definition. Specific 
> comments below.
>
>   

> required? RFC4966 lists this as one of the drawbacks for NAT-PT.
the behave requirements require to use of timeouts, but since we also have endpoint independets mappings, we need to track each session that is being used by each endpoint. In order to do that the proposed approach is to have timers in the session table entries. SO as long as there is at least one session table associated to a BIB entry, the BIB entry is preserved, When all session table entries associated to a BIB entry are deleted, the BIB entry is deleted.
So, While the BIN entries do have an explicit timer, they are bound to the timers of the corresponding session table entries, so they do have a timer expiration.

[Senthil] I guess in the above paragraph you mean the BIB entries don't have an explicit timer but tied to the session timer. I am fine with that, my concern was wrt RFC4966 raising that as an issue.

> - RFC4966 is mentioned in Section 1 and it is mentioned that a number 
> of features have been added to overcome the reasons of deprecation of 

Right, we could try to do this, if people find it important. Another thing that would be also interesting would be to explain how the NAT64 complies with the behave requirements for UDP, TCP and ICMP.

Both of these excersises would be good to have in the document as appendixes.

[Senthil] Ok, I would like to address the issues arised by RFC4966 in this document, even though I know a lot of issues mentioned in RFC4966 is generic to any NAT, I think it will useful to document that we have considered these issues and either addressed them or decided not to address them.

>  Because I still see a number of issues discussed in RFC 4966 applies 
> to this document as well - like ALGs, Binding state decay, Dos 
> attacks, Loss of information through incompatible semantics (actually 
> applies to stateless) etc.
>
> Specific comments.
> -------------------
>
fixed

> Section 1.2
>
> NAT64 mechanism is implemented in an NAT64 box which has two 
> interfaces should be
>
ok

> algorithmically/statically map the IPv4 addresses into IPv6 addresses. 
> I would suggest that you use the terminology of algorithmically 
> extracting the IPv4 address and algorithimically adding the prefix to 
> form the v6 address.
>
>   

       <t>The IPv6 address pool is an IPv6 prefix assigned to the translator
       itself (hereafter called Pref64::/n). Due to the abundance of
IPv6 address space,
       it is possible to assign an Pref64::/n that is equal or even bigger than the whole IPv4 address space. This allows
       each IPv4 address to be mapped into a different IPv6 address by simply
       concatenating the Pref64::/n with the IPv4 address being mapped and a suffix (i.e. an IPv4 address X is
       mapped into the IPv6 address Pref64:X:SUFFIX). The provisioning of the Pref64::/n is
        discussed at length in <xref
target="I-D.ietf-behave-address-format" /> </t>

[Senthil] Reads good.

> Section 1.2.3
>
> I don't understand this
>
> "Filtering on the IPv6 interface is not supported, as mappings are 
> only created by packets traveling in the IPv6 --> IPv4 direction."
>
good question
NAT64 supports dynamically initiated connections only from the IPv6 side. So filtering on the IPv6 side seems some how orthogonal to the NAT behaviour. I mean you could do that, but you wouldn't be using NAT state in order to do so, i think.
OTOH, filtering in the IPv4 interface is different. Since NAT64 cannot support communications iniitated in the IPv4 side, when there is a hole in the NAT opened by an IPv6 connection and because we are doing endpoint independent mappings, we end up with the question on whehter we do accept this new communication that has been initiated from the IPv4 side or not (keep in mind that this is possible only because there is a hole open and would not be possible in other case)

So, while the NAT could filter in the IPv6 interface, this seems to be orthogonal to the NAT behaviour, but filtering in the IPv4 interface i tightly couple to the nat64 state, hence need to be specified.

      Filtering of incoming IPv6 packets is not described in this specification.

[Senthil] I guess I was thinking filtering even before the session can be created. 
For example, one would want all the IPv6 hosts to have access to internet but except for a handful of specific hosts. Another filtering technique is all hosts are allowed except the ones that talk to a specific port or set of ports. These types of filtering is common and they protect the NAT64 resources (addresses & ports). 

in order to make it clearer that is not that is not supported, but that is not specified here.

So, the 3-tuple refers to the ICMP case. Not sure how to reword the document to make this more clear.

> and 3-tuple for ICMP. So I don't see why the 5-tuple searches 
> mentioned in the later sections are required.
>
>   
mmm, i see what you mean.
OTOH, you could think that you actually search using the 5-tuple, since the protocol value in the 5-tupel determines which table (UDP or TCP) you need to search.
We could use a 4-tuple for the 2 case, and we would need to define what the 4-tuple is and how it relates to the 5-tuple. IMHO, this would render the document less clear, but we can discuss further it you want.

[Senthil] My confusion is this, if you have the tables as one big monolithic table for TCP, UDP and ICMP then it is a 5-tuple search, if not it is a 4-tuple search. The document calls for protocol specific tables but mentions 5-tuple search, which is inconsistent. The second inconsistency is 5-tuple search for tcp/udp but 3 tuple search for icmp. I mean, if it is a 5-tuple search for tcp/udp it should be a 4-tuple search for icmp. I feel it is more confusing if we leave it the way it is. We may want to ask WG if anyone else find this confusing or if it is just me.

> Paragraph 2 "Irrespective ..." does this apply only to stateful NAT64 
not sure if it applies to the stateless, it certainly applies to the statefull translator, agree?

[Senthil] Yes, it definitely applies to stateful, I thought it will also apply to stateless and hence if it should belong in the stateless, maybe? 

right, see comment above

fixed

> NAT64 devices to track the sessions with the described state machine? 
> Is it a MUST, SHOULD, MAY, recommend?
>   
This is similar to the the TCP spec. It does have a state machine, you can implement it in this way, you could do it in a different way as long as the external behaviour is the same.

       <t>This breakdown of the NAT64 behavior into processing steps is done
       for ease of presentation. A NAT64 MAY perform the steps in a different
       order, or MAY perform different steps, as long as the externally
       visible outcome is the same.</t>

The closed state is somehow special, cause it means that there is no state for the particular connection. I have tried to make this clearer in the document by adding the following description:

                    <t>CLOSED: Analogous to <xref target="RFC0793"></xref>, CLOSED is a fictional
                      because it represents the state when there is no state for this particular 5-tuple, and therefore,
                      no connection.</t>

[Senthil] The state of a session is tracked via the session table, but the text indicates that all the TCP sessions are in closed state. My question is what is this "all TCP sessions" and how do you track a session state without a session. 

> entry and state tracking starts when the entry is created and stops 
> when the entry is destroyed.
mmm, i don't think you can keep track of all the state information using only the information stored in the session table. In order to keep track of the state informtation, you will likely have to keep track to the state information in addition to that information in the tables.

[Senthil] Agreed, but the state information is keyed off of session table. That is, if you don't have a session entry you cannot(and don't have to) keep track state information for that session entry, 

> So what is this CLOSED state and where is it tracked? This is very 
> unclear and confusing.
>
>   

> session is created where does this state hang off of?
I have moved the order to the sentence, so that first the session entry is created and then the sta
te is moved to V6 SYN RCV, would that help?

[Senthil] Yes. 

fixed

> section but this needs some serious explanation and clarifying.
I have made many changes aiming to clarify this in the 04 version. Could you check it and see if it clearer now?

[Senthil] Ok, I will be travelling tomorrow, this would be a good read.

> Section 3.2.3
>
> For port allocation, the text says if the port is even an even port 
> must be allocated and same for odd. What if there are no even ports to 
> it a mandatory requirement sounds unreasonable. Note RFC 4787 
> recommends this behavior but this text mandates it.
>   

[Senthil] I am thinking that this should be a configurable parameter, that is the admin can decide if the device should strictly allocate even-for-even and odd-for-odd or it should do the first available port. 

Senthil

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 15 Dec 2009 22:07:42 +0100

> [Senthil] My question was more in the lines of must every NAT64 device implement these 3 BIB tables  and 3 Session tables. For example, you could achieve the same with 1 BIB table and 1 session tab…
sure, that is the intended meaning.
I have added the follwoing text:

        <t>These tables contain information needed for the NAT64 
processing. The actual
             division of the information into six tables is done in 
order to ease the
            description of the NAT64 behaviour. NAT64 implementations 
MAY use different data structures
            as long as they store all the required information and the 
externally
               visible outcome is the same as the one described in this 
document.</t>

> [Senthil] Ok, I would like to address the issues arised by RFC4966 in this document, even though I know a lot of issues mentioned in RFC4966 is generic to any NAT, I think it will useful to documen…
i have no issues with that

> in order to make it clearer that is not that is not supported, but that is not specified here.

right, i agree with that, but i still think this is orthogonal to the 
nat64 (e.g. firewalls have the same issues) so i am not sure what to say 
about this in the draft... any suggestion?

> [Senthil] My confusion is this, if you have the tables as one big monolithic table for TCP, UDP and ICMP then it is a 5-tuple search, if not it is a 4-tuple search. The document calls for protocol…

i see what you mean, but i am not yet convinced this is an issue
I mean, the 5-tuple is widely used, so using 4-tuple doesn't seem very 
intuitive to me
Making searches using the 5-tuple, as i mentioned can be read as using 
the protocol value to select whic table you search and then using the 4 
reamining values to search within the table.
In the ICMP case, you don't need that cause there is only one table to 
search using the 3-tuple

Don't get me wrong, i perfectly see the comment you make and i can see 
you can see it as an inconsistency.
My comment is that people are used to use the 5-tuple for identifying 
connections, so using 4-tuples is not very intuitive, so i rather keep 
it as it is (even if this can be interpreted as the inconsistency you 
mention)

> [Senthil] Yes, it definitely applies to stateful, I thought it will also apply to stateless and hence if it should belong in the stateless, maybe? 
maybe you should bring this issue as a comment to the stateless draft, 
not sure what i can do in the statefull draft w.r.t. this

> [Senthil] The state of a session is tracked via the session table,
no.
the state is tracked by the state. I mean, current session table does 
not have a "STATE" column defined.Additional data is needed to track the 
state, sicne the state a given connection is is a piece of information 
that needs to be stored somewhere. We could define all the data 
strcutures needed for the implementation, but i fail to see the need for 
that

>  but the text indicates that all the TCP sessions are in closed state. My question is what is this "all TCP sessions" and how do you track a session state without a session. 
>
>   
as i mentioned earlier, the CLOSED state is a fictional state (similar 
to the the one for TCP) that represents that there is no state for a 
connection.
In other words, in a normal TCP stack (in any regular host, no nat64 
involved) all non existent  connections are in CLOSED state... so where 
does a TCP stack store the state for those connections? Nowhere, cause 
the CLOSED stated in fact means that there is no state.

So, if there is no state, then it is closed state. Similar to the NAT64

> [Senthil] Agreed, but the state information is keyed off of session table. That is, if you don't have a session entry you cannot(and don't have to) keep track state information for that session ent…
see above, you don't need to track state for the entries that do not 
have a session table entry. If there is no state, then it is in closed state

> [Senthil] I am thinking that this should be a configurable parameter, that is the admin can decide if the device should strictly allocate even-for-even and odd-for-odd or it should do the first ava…
but that is not what is reccomended by the behave requirements, right?

I mean, what is required is what you mentioned earlier and that i have 
tried to relfect in the document with the text above.
If we want to reccomend something else than what is described in the 
behave requirements, then we need to go against prior consensus. We can 
do that, but it would require strong WG consenus.

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Dec 2009 10:54:28 +1300

> Senthil Sivakumar (ssenthil) escribió:

...
>>> databases for TCP/UDP/ICMP, the search is based on 4 tuple for
>>> TCP/UDP and 3-tuple for ICMP. So I don't see why the 5-tuple searches
>> OTOH, you could think that you actually search using the 5-tuple,
>> since the protocol value in the 5-tupel determines which table (UDP or
>> TCP) you need to search.
>> We could use a 4-tuple for the 2 case, and we would need to define
>> what the 4-tuple is and how it relates to the 5-tuple. IMHO, this
>> would render the document less clear, but we can discuss further it
>> you want.
>>
>> [Senthil] My confusion is this, if you have the tables as one big
>> monolithic table for TCP, UDP and ICMP then it is a 5-tuple search, if
>> not it is a 4-tuple search. The document calls for protocol specific
>> tables but mentions 5-tuple search, which is inconsistent. The second
>> inconsistency is 5-tuple search for tcp/udp but 3 tuple search for
>> icmp. I mean, if it is a 5-tuple search for tcp/udp it should be a
>> 4-tuple search for icmp. I feel it is more confusing if we leave it
>> the way it is. We may want to ask WG if anyone else find this
>> confusing or if it is just me.
>>   
> 

Just to add some more confusion, we could also imagine a situation
in the future where non-zero flow labels are found in the incoming
IPv6 packets. Theoretically, that allows a different 3-tuple {src, dest,
flow_label}. I'm not sure we want to talk that, but an implementation
note recommending flexibility in the n-tuple design might be useful.

    Brian

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Tue, 15 Dec 2009 21:20:44 -0800

-----Original Message-----
From: marcelo bagnulo braun [mailto:[email-masked]] 
Sent: Tuesday, December 15, 2009 4:08 PM
To: Senthil Sivakumar (ssenthil)
Cc: [email-masked]
Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-stateful-03.txt

Senthil Sivakumar (ssenthil) escribió:
> Subject: Re: [BEHAVE] Comments on 
> draft-ietf-behave-v6v4-xlate-stateful-03.txt
>
> Hi,
>
> thanks for the review
>
> see replies below...
>

        <t>These tables contain information needed for the NAT64 processing. The actual
             division of the information into six tables is done in order to ease the
            description of the NAT64 behaviour. NAT64 implementations MAY use different data structures
            as long as they store all the required information and the externally
               visible outcome is the same as the one described in this document.</t>

>> NAT-PT. I wonder if there should be a section discussing what has 
>> been overcome and how.
>>     
>

> support communications iniitated in the IPv4 side, when there is a 
> hole in the NAT opened by an IPv6 connection and because we are doing 
> endpoint independent mappings, we end up with the question on whehter 
> we do accept this new communication that has been initiated from the 
> IPv4 side or not (keep in mind that this is possible only because 
> there is a hole open and would not be possible in other case)
>

right, i agree with that, but i still think this is orthogonal to the
nat64 (e.g. firewalls have the same issues) so i am not sure what to say about this in the draft... any suggestion?

[Senthil] True. I was thinking some text along these lines.

"NAT64 device can do filtering of IPv6 packets based on the administrative rules to create BIB and session entries. The filtering can be flexible enough and broad enough but the idea of the filtering is to provide the operators necessary control to avoid DoS attacks that would result in exhaustion of NAT64 address, port, memory and CPU resources".

> [Senthil] My confusion is this, if you have the tables as one big monolithic table for TCP, UDP and ICMP then it is a 5-tuple search, if not it is a 4-tuple search. The document calls for protocol…

i see what you mean, but i am not yet convinced this is an issue I mean, the 5-tuple is widely used, so using 4-tuple doesn't seem very intuitive to me Making searches using the 5-tuple, as i mentioned can be read as using the protocol value to select whic table you search and then using the 4 reamining values to search within the table.
In the ICMP case, you don't need that cause there is only one table to search using the 3-tuple

Don't get me wrong, i perfectly see the comment you make and i can see you can see it as an inconsistency.
My comment is that people are used to use the 5-tuple for identifying connections, so using 4-tuples is not very intuitive, so i rather keep it as it is (even if this can be interpreted as the inconsistency you
mention)

[Senthil] Actually most TCP stack implementors use 4-tuple a lot, but I agree with you that in NAT world we do use 5-tuple. But as Brian Carpenter has indicated in another email we have more tuples depending on existing needs & future needs. In many Cisco NAT devices we currently have 6-tuple searches. In any case, I would be fine if the consensus of the working group is to leave it as is and it is not confusing. 

> [Senthil] Yes, it definitely applies to stateful, I thought it will also apply to stateless and hence if it should belong in the stateless, maybe? 
maybe you should bring this issue as a comment to the stateless draft, not sure what i can do in the statefull draft w.r.t. this

[Senthil] Ok, will do. 

>> Why should the search be based on the 5-tuple, since it is UDP 
>> session table the search is based on the 4-tuple of (SrcIP, DstIP, 
>> SrcPort, DstPort).
>>
no.
the state is tracked by the state. I mean, current session table does not have a "STATE" column defined.Additional data is needed to track the state, sicne the state a given connection is is a piece of information that needs to be stored somewhere. We could define all the data strcutures needed for the implementation, but i fail to see the need for that

[Senthil] Let me ask you this, as an implementor when the doc says "After bootstrapping all the devices should set its connection state for all the sessions to CLOSED." How do I do that? 
Again, I didn't mean to say the state should be tracked within a session, but the state is per-session and hence keyed off of the session. You cant get to the state of the session without knowing what the session keys are. 

>  but the text indicates that all the TCP sessions are in closed state. My question is what is this "all TCP sessions" and how do you track a session state without a session. 
as i mentioned earlier, the CLOSED state is a fictional state (similar to the the one for TCP) that represents that there is no state for a connection.
In other words, in a normal TCP stack (in any regular host, no nat64
involved) all non existent  connections are in CLOSED state... so where does a TCP stack store the state for those connections? Nowhere, cause the CLOSED stated in fact means that there is no state.

[Senthil] In TCP, there is a transition from CLOSE_WAIT to CLOSED and there is a time period when the connections are in CLOSED state. (I don't recall the whole state diagram now) but the CLOSED state is tied to an existing TCP session at some point of time in the life cycle of the connection. Is there a  state progression for the TCP states in NAT64 too, if so I must have missed that.

> [Senthil] Agreed, but the state information is keyed off of session 
> table. That is, if you don't have a session entry you cannot(and don't 
> have to) keep track state information for that session entry,
>
>   
see above, you don't need to track state for the entries that do not have a session table entry. If there is no state, then it is in closed state

> I have moved the order to the sentence, so that first the session 
> entry is created and then the sta te is moved to V6 SYN RCV, would that help?
>
> [Senthil] Yes. 
>
>   
>> Section 3.2.2
>>
>> must be allocated and same for odd. What if there are no even ports 
>> to allocate but there are odd ports, should the packet be dropped or 
>> making this a recommendation on the best effort basis is ok but 
>> making it a mandatory requirement sounds unreasonable. Note RFC 4787 

I mean, what is required is what you mentioned earlier and that i have tried to relfect in the document with the text above.
If we want to reccomend something else than what is described in the behave requirements, then we need to go against prior consensus. We can do that, but it would require strong WG consenus.

[Senthil] From RFC4787,

REQ-4:  It is RECOMMENDED that a NAT have a "Port parity
      preservation" behavior of "Yes".

It does not say SHOULD. So what you have in this draft is going above what has been said in the RFC4787.

Thanks
Senthil

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 16 Dec 2009 14:01:07 +0100

> "NAT64 device can do filtering of IPv6 packets based on the administrative rules to create BIB and session entries. The filtering can be flexible enough and broad enough but the idea of the filteri…
Ok, i will add that text to the draft, thanks

> [Senthil] Let me ask you this, as an implementor when the doc says "After bootstrapping all the devices should set its connection state for all the sessions to CLOSED." How do I do that? 

you don't create any state for any connection, hence they are all in 
CLOSED state.

> Again, I didn't mean to say the state should be tracked within a session, but the state is per-session and hence keyed off of the session. You cant get to the state of the session without knowing w…
the keys are the connection identifier.
You search among the connections that have state, If you can't find 
state for the connection you are searching, it means it is in closed state.
Again, CLOSED state is a _fictional_ state that represents that no state 
is available for that connection and hence there is no connection.

Again, this is exactly the same as 793,

> [Senthil] In TCP, there is a transition from CLOSE_WAIT to CLOSED and there is a time period when the connections are in CLOSED state. 

from RFC793 page 21

  CLOSED is fictional
  because it represents the state when there is no TCB, and therefore,
  no connection.

and then in page 22

    CLOSED - represents no connection state at all.

> It does not say SHOULD. 

 From RFC 2119:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

> So what you have in this draft is going above what has been said in the RFC4787.
>
>   
not sure i understand what you mean

Regards, marcelo

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 18 Dec 2009 11:01:14 -0800

-----Original Message-----
From: marcelo bagnulo braun [mailto:[email-masked]] 
Sent: Wednesday, December 16, 2009 8:01 AM
To: Senthil Sivakumar (ssenthil)
Cc: [email-masked]
Subject: Re: [BEHAVE] Comments on draft-ietf-behave-v6v4-xlate-stateful-03.txt

Senthil Sivakumar (ssenthil) escribió:
>> OTOH, filtering in the IPv4 interface is different. Since NAT64 
>> cannot support communications iniitated in the IPv4 side, when there 
>> is a hole in the NAT opened by an IPv6 connection and because we are 
>> doing endpoint independent mappings, we end up with the question on 
>> whehter we do accept this new communication that has been initiated 
>> from the

>>> What does it mean all TCP sessions are in closed state? Where is 
>>> this tracked?
>>>   
>>>     
>>>       
> not have a "STATE" column defined.Additional data is needed to track 
> the state, sicne the state a given connection is is a piece of 
> information that needs to be stored somewhere. We could define all the 
> data strcutures needed for the implementation, but i fail to see the 
> need for that
>

you don't create any state for any connection, hence they are all in CLOSED state.

from RFC793 page 21

  CLOSED is fictional

and then in page 22

[Senthil] Ok, I am fine with the text as is. Just for clarity can you add a reference to 793 when you are describing CLOSED?

 From RFC 2119:

[Senthil] Ok. That sounds good.

Thanks
Senthil

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 19 Dec 2009 21:56:34 +0100

> [Senthil] Ok, I am fine with the text as is. Just for clarity can you add a reference to 793 when you are describing CLOSED?
it is already in the draft:

it reads:

     CLOSED: Analogous to [RFC0793], CLOSED is a fictional state
      because it represents the state when there is no state for this
      particular 5-tuple, and therefore, no connection.

Regards, marcelo