Re: [OPSAWG] CLAT (was TR: New Version Notification for draft-ietf-opsawg-nat-yang-00.txt)

[JORDI PALET MARTINEZ <[e-mail]>]

Hi Med,

Looks good to me, and I think it covers all the possible options, which one exception:

                 +--rw clat-ipv4-address?            inet:ipv4-address

You may want to use a prefix, not an address. If you have a CLAT serving a “big” network, instead of a small CE, you may need to use a pool of several IP addresses. For example, in a recent testing, I used for the stateless CLAT (NAT46) the following EAMT (Explicit Address Mappings Table, RFC7757):

Pool IPv4/NAT46: 100.64.0.0/10
Pool IPv6: 2001:470:68ee:30::/106

(I was a bit exaggerated here, with so big pool, but is only an example)

So may be something like:
+--rw clat-ipv4-address?            inet:ipv4-address
+--rw clat-ipv4-mask?            inet:ipv4-mask

Note that I’m NOT expert in YANG, but I just read thru all your ID and looks ok.

Some other details that you may want to consider:
1) Say something about CLAT/NAT46/464XLAT in the abstract.
2) Same for the intro.
3) Same in section 2.2.
4) You may need to add also something in 2.8, at paragraph:
In order to cover both NAT64 and NAT44 flavors in particular, the NAT
   mapping structure allows to include an IPv4 or an IPv6 address as an
   internal IP address.  Remaining fields are common to both NAT
   schemes.
5) Also I think in 2.8 “Note that a mapping table is maintained only for stateless NAT” you actually mean stateful NAT ?
6) You could also rewrite (2.8) “Obviously, no mapping table is maintained for NPTv6 given that it is stateless and transport-agnostic” as “Obviously, no mapping table is maintained for any stateless NAT (such as NAT46), neither for NPTv6 given that it is stateless and transport-agnostic”
7) Instead of +--rw subscriber-mask-v6?, should mask be prefix-length?
8) In section 3, I see you have some “code” for each NAT type, so you may need also for NAT46?
9) And of course, you may want to add a CLAT example at the appendix ;-)

Hope it helps!

Saludos,
Jordi
 

-----Mensaje original-----
De: <[e-mail]>
Responder a: <[e-mail]>
Fecha: viernes, 18 de agosto de 2017, 16:19
Para: Lee Howard <[e-mail]>, "[e-mail]" <[e-mail]>
CC: "[e-mail]" <[e-mail]>, JACQUENET Christian IMT/OLN <[e-mail]>, "Senthil Sivakumar (ssenthil)" <[e-mail]>, Qin Wu <[e-mail]>, "[e-mail]" <[e-mail]>
Asunto: CLAT (was TR: New Version Notification for draft-ietf-opsawg-nat-yang-00.txt)

    Hi Lee,
    
    (I'm adding Jordi to the discussion since he is familiar with CLAT in a CPE)
    
    You suggested in Prague to add CLAT to the NAT YANG module. 
    
    Please find below how we are planning to cover it in the next iteration of the draft:
    
    (1) If a dedicated prefix is configured for CLAT, then only a stateless XLAT will be required. That is, no mapping table will be maintained at all. Since the module already includes NAT64 prefix(es), the CLAT IPv6 prefix will be missing. The tree structure can be updated as follows:
    
    OLD:
                 +--rw nat64-prefixes* [nat64-prefix]
                 |  +--rw nat64-prefix               inet:ipv6-prefix
                 |  +--rw destination-ipv4-prefix* [ipv4-prefix]
                 |     +--rw ipv4-prefix    inet:ipv4-prefix
    
    NEW:
    
                 +--rw nat64-prefixes* [nat64-prefix]
                 |  +--rw nat64-prefix               inet:ipv6-prefix
                 |  +--rw destination-ipv4-prefix* [ipv4-prefix]
                 |     +--rw ipv4-prefix    inet:ipv4-prefix
                 +--rw clat-ipv6-prefix?             inet:ipv6-prefix
    
    (2) If no dedicated /64 prefix is provided, a NAT44 will be required. A stateless XLAT will be then applied on NATed packets. This case is natively supported by the current YANG model. 
    
    A CLAT module can automatically select an IPv4 address from 192.0.0.0/29 (RFC7335). This address can also be set. To do so, the tree structure can be updated with:  
    
    NEW:
                 ...      
                 +--rw clat-ipv4-address?            inet:ipv4-address 
                 ...
    
    The CLAT IPv4 address will be taken by default from 192.0.0.0/29. Other addresses can be used.
    
    Lee/Jordi, are there any other required changes?
    
    Thank you.
    
    Cheers,
    Med
    
    > -----Message d'origine-----
    > De : OPSAWG [mailto:[e-mail]] De la part de
    > [e-mail]
    > Envoyé : vendredi 18 août 2017 15:46
    > À : [e-mail]
    > Cc : [e-mail]; JACQUENET Christian IMT/OLN
    > Objet : [OPSAWG] TR: New Version Notification for draft-ietf-opsawg-nat-
    > yang-00.txt
    > 
    > Dear all,
    > 
    > The -00 version integrates the comments received during the Call for
    > Adoption:
    > 
    > - Clarify how Destination NAT is covered (Tianran)
    > - Follow the NMDA guidelines (Juergen and Qin)
    > - Include a generic structure for ALGs instead of listing supported ones
    > (Juergen)
    > - Include a discussion about how other transport protocols are/can be
    > supported (Juergen)
    > - Include a comprehensive list of examples  (Juergen)
    > - Move the example to an appendix (Juergen)
    > 
    > We do still have one pending comment that was raised by Lee Howard when I
    > presented in Prague: add CLAT to the list.
    > 
    > Comments are more than welcome. Please review.
    > 
    > Cheers,
    > Med
    > 
    > > -----Message d'origine-----
    > > De : [e-mail] [mailto:[e-mail]]
    > > Envoyé : vendredi 18 août 2017 15:31
    > > À : BOUCADAIR Mohamed IMT/OLN; Senthil Sivakumar; JACQUENET Christian
    > > IMT/OLN; [e-mail]; Qin Wu
    > > Objet : New Version Notification for draft-ietf-opsawg-nat-yang-00.txt
    > >
    > >
    > > A new version of I-D, draft-ietf-opsawg-nat-yang-00.txt
    > > has been successfully submitted by Mohamed Boucadair and posted to the
    > > IETF repository.
    > >
    > > Name:		draft-ietf-opsawg-nat-yang
    > > Revision:	00
    > > Title:		A YANG Data Model for Network Address Translation (NAT) and
    > > Network Prefix Translation (NPT)
    > > Document date:	2017-08-18
    > > Group:		opsawg
    > > Pages:		67
    > > URL:            https://www.ietf.org/internet-drafts/draft-ietf-opsawg-
    > > nat-yang-00.txt
    > > Status:         https://datatracker.ietf.org/doc/draft-ietf-opsawg-nat-
    > > yang/
    > > Htmlized:       https://tools.ietf.org/html/draft-ietf-opsawg-nat-yang-
    > 00
    > > Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
    > > nat-yang-00
    > >
    > >
    > > Abstract:
    > >    For the sake of network automation and the need for programming
    > >    Network Address Translation (NAT) function in particular, a data
    > >    model for configuring and managing the NAT is essential.  This
    > >    document defines a YANG data model for the NAT function.  NAT44,
    > >    NAT64, and NPTv6 are covered in this document.
    > >
    > >
    > >
    > >
    > > Please note that it may take a couple of minutes from the time of
    > > submission
    > > until the htmlized version and diff are available at tools.ietf.org.
    > >
    > > The IETF Secretariat
    > 
    > _______________________________________________
    > OPSAWG mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/opsawg
    





**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.