Subject: Re: I-D Action:draft-ietf-v6ops-nat64-pb-statement-req-00.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 17 Jul 2008 16:31:11 +0200

Hi Brain,

thanks for the comments, i am working on this

see comemnts and a few questions below...

Brian E Carpenter escribió:
> Hi,
>
> A few comments:
>
>   
>> 2.1.  Transition scenarios
>>
>>    There are six obvious transition scenarios:
>>     
>
> I think we can avoid off-topic reactions by changing this
> slightly:
>
>    There are six obvious IP layer transition scenarios:
>
>   
done

> and adding underneath something like
>
>    Transition scenarios involving the use of upper layer proxies
>    have their place, but are out of scope for this document.
>
>   
done

>> 2.1.3.  Transition scenarios that require translation
>>     
>
> I think there's a point that should be made in this section:
>
> In practice, it is highly likely that addresses will be in short
> supply in the IPv4-only domain, and therefore that address sharing
> and port mapping will be required. These functions may or may not
> be combined with the IPv6-IPv4 translation function.
>
>   
done

>> 3.3.  v4 addressing consideration
>>     
> ...
>   
>>    ...The case where the v4-only node has a
>>    private v4 address and the NAT64 box has a public address seems also
>>    possible, but here it seems reasonable to assume that a NAT box will
>>    exist between the v4 only node and the NAT64 box.  
>>     
>
> There is an alternative assumption which is that traditional NAT
> (v4 to v4) is embedded in the NAT64 device. There is a difference,
> because then the NAT64 is aware of the address and port mappings
> (and that opens some possibilities, as SHANTI and MNAT-PT show).
>
>   
added that the nat44 can be colocated with the nat64 box

>> 3.4.  Name-space considerations
>>
>>    One of the major choices that are faced when designing a NAT4
>>    mechanism that enable communication initiated by the v4-only node
>>    towards a v6-only node.  In this case, the v4 only node needs to
>>    identify the v6 only node and the problem is that there is no means
>>    to permanently map the v6 address space in the v4 address space.  
>>     
>
> Well yes, that is unsolvable, so let's not try to solve it.
> This returns to point about port mapping - if you want the NAT64 to
> support incoming sessions, the number of sessions is limited by
> (number of ports)*(number of IPv4 addresses). In DNS, the IPv6-only
> servers will have to be represented by a shared A record for each
> IPv4 address. That doesn't require a DNS ALG. But it does require
> defined mappings for inbound ports. That's NAT 101, and the mapping
> to IPv6 doesn't change it.
>
>   

right, not sure if you want me to do somehting about this in the document?
>>    o  R2.2: Translation mechanim must support v4-initiated short-lived
>>       local handle (as defined in Section 3.1). (not clear if there is
>>       consensus for this)
>>     
>
> I think that if we're going to do this at all, it needs to be symmetrical,
> so I hum for this.
>
>   
ok

same question that i have done to Dan, do you think servers can be 
located in v6 land or only peers? (i.e. p2p applications with v4 and v6 
peers)

>>    o  R2.2.1: v4 initiators can either use IPv4 public addresses or IPv4
>>       private addresses and use a NAT.(The acceptance of R2.2.1 is
>>       subject to the acceptance of R2.2.
>>     
>
> As noted above, that does *not* imply a separate NAT; it could be combined
> with the NAT64.
>
>   
cahnges nat by nat function, ok?

thanks, marcelo
>   Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 17 Jul 2008 16:48:29 +0200

Hi Phillip,

thanks for the review

I am trying to work on your comments but i havne't been able to actually 
reflect any changes in the document so far... see below

Philip Matthews escribió:
> Some comments on this draft, from the perspective of someone familiar 
> with the various BEHAVE documents.
>
> * R6 lists TCP, UDP, ICMP, and TLS as protocols to be supported. I am 
> surprised that TLS is listed in addition to TCP, since full TCP 
> support would imply TLS.
is this so?
If yes, it seems that needs to be removed, should we?

> I am also surprised that DTLS is not listed, if listing TLS is seen as 
> necessary. Any explanation for this?
>

> * R7 lists the BEHAVE requirement documents for TCP and UDP. Is there 
> some reason for not listing the BEHAVE requirement document for ICMP?
>
well, behave req for tcp and udp are included to make sure that ICE works

do we need to comply with icmp reqs to make ice work?

is there other reasons why we should include icmp reqs?

> * R8 talks about fragmented packets. Is there some reason to include 
> this specifically, given that the BEHAVE requirements cover 
> fragmentation in some detail?
do you think that we should simply refer to the behave document for this 
and remove this req?
aren't the behave req v4 specific? i mean, do they apply to v6 fragments?
> The BEHAVE requirements do not mention the 5 second stuff, but they 
> talk about out-of-order fragments which R8 does not mention.
>
the current version covers in order and out of order packets

> * I6 and I7 talk about SCTP and DCCP support. Is it acceptable to 
> support these by transporting them over UDP?
>
don't know, do you think we need to be explicit about it? why?

> * I8 talks about multicast. Should multicast support comply with the 
> BEHAVE requirement document for multicast?
>
don't know, what do you think?

> * A (long) comment on R2.
> There is a class of applications that work today through NAT44s. As a 
> general rule, these are applications that do not carry addresses 
> embedded inside protocol messages, and have communication initiated by 
> the host behind the NAT. Is this the same class of applications that 
> should be supported by the proposed translation mechanism?
>
well, i think it is a subset, cause we only require client server with 
v4 clients. p2p communications are considered in I4, cause they require 
host support

> Code in a NAT that recognizes packets of a specific application 
> protocol and does special processing of that packet is known as an ALG 
> (Application Level Gateway). The BEHAVE group considers an FTP ALG to 
> be acceptable, because FTP was there before NATs, but other ALGs are 
> discouraged (= default off). Is this rule consistent with the proposed 
> transition mechanism?  This rule is given in RFC 4787, which R7 says 
> the mechanism must comply with.
>
> If so, is R2 an attempt to formalize all this in different words?
>
i don't think so, as i mention above, it seems more restricitive than that

Regards,marcelo

> - Philip
>
>
>
> On Tue, 13-May-08, at 19:30 , [email-masked] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the IPv6 Operations Working Group of the 
>> IETF.
>>
>>
>>     Title           : IPv4/IPv6 Coexistence and Transition: 
>> Requirements for solutions
>>     Author(s)       : M. Bagnulo, et al.
>>     Filename        : draft-ietf-v6ops-nat64-pb-statement-req-00.txt
>>     Pages           : 17
>>     Date            : 2008-05-13
>>
>> This note presents the problem statement, analysis and requirements
>> for solutions to IPv4/IPv6 coexistence and eventual transition in a
>> scenario in which dual stack operation is not the norm.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nat64-pb-statement-req-00.txt 
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> <mime-attachment>
>
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Jul 2008 15:01:41 +1200

On 2008-07-18 02:31, marcelo bagnulo braun wrote:
...
> located in v6 land or only peers? (i.e. p2p applications with v4 and v6

Ideally both. If we place any restrictions they will cause a problem
in 5, 10 or 15 years time.

> cahnges nat by nat function, ok?

Yes, we'd better not over-design in the requirements stage.

   Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 19 Jul 2008 16:45:09 +0200

> in 5, 10 or 15 years time.
this seems to be a clear case of no consensus, i am afraid, and i am not 
sure what to do about this

i will raise the question in the meeting and try to figure this one out 
there

> Yes, we'd better not over-design in the requirements stage.
will do

regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 20 Jul 2008 11:55:55 +0200

On 18 jun 2008, at 8:32, <[email-masked]> <[email-masked] 
 > wrote:

>> In a previous modified-nat-pt draft I wrote about the v4-v6-v4
>> case where IPv4 clients sit behind a CPE or layer in the stack
>> that translates their IPv4 packets into IPv6 packets using SIIT (=
>> stateless) and then the resulting IPv6 packets flow through the same
>> NAT64 translators that IPv6 hosts that want to talk to the
>> IPv4 world also use.

>> Expect to see a new or updated draft on this topic before Dublin.

> I'm looking forward to it.

Unfortunately, other work came up so I didn't have time for this  
before the deadline... This is text from an expired draft:

http://www.muada.com/drafts/draft-van-beijnum-modified-nat-pt-02.txt

5.  IPv4-IPv6-IPv4 operation

    It would be optimistic to expect that all hosts implement IPv6 and
    the mechanisms outlined above within a limited timeframe.  As such,
    it is useful to support both hosts that don't implement the changes
    set forth in this document, and even hosts that don't implement IPv6
    at all.  In these cases, a gateway device may be employed that
    manages a block of private IPv4 address space using DHCP and
    translates these to IPv6 addresses.  The local device performs SIIT
    between the resulting IPv4 and IPv6 address pairs but not IPv4 NAT.

    Since the remote translator that translates from IPv6 to public IPv4
    requires a unique IPv6 address in order to demultiplex, the local
    gateway MUST use a dedicated IPv6 address for each local IPv4
    address.  Any [RFC1918] address may be used locally as long as the
    requirements are met that only a single local IPv4 address maps to  
an
    IPv6 address, and that the addresses are equivalent for the purposes
    of computing checksums.  A way to conform to these requirements is  
to
    construct the IPv6 address from the IPv4 address as follows:

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    | 64-bit subnet prefix  |F0|ID|CHKSM| IPv4 addr |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

    Bit 70 in the address MUST be set to 0 to indicate a non globally
    unique address.  The ID bits can contain a value that allows
    different gateways to live on the same subnet.  In the absence of  
any
    administrative settings or the detection of duplicate addresses,  
this
    could be the lower 8 bits of the gateway's MAC address.  The CHKSM
    bits are chosen such that they compensate for the differences in the
    checksum generated over the IPv4 pseudo-header and the checksum
    generated over the IPv6 pseudo-header.  This means that this value  
is
    the one's complement of the one's complement addition of the 16-bit
    words from the top 96 bits of the address of remote modified NAT-PT
    translator and all the 16-bit words from the top 80 bits of IPv6
    address that is being constructed.

    The local gateway SHOULD also perform IPv6 routing or otherwise  
allow
    IPv6 connectivity so that hosts that do support IPv6, but not
    MNAT-PT, have the ability to communicate directly over IPv6 in
    addition to being able to use translated IPv4 connectivity.

    There are two open issues: how do IPv4 hosts using different local
    gateways but the same modified NAT-PT translator communicate, and  
how
    do NAT traversal protocols such as uPnP, NAT-PMP and others work.

> We should have a solution available that
> includes client side changes

Hm, client side modifications for 4-6-4 operation doesn't seem very  
useful...