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

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

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