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: <[email protected]>
Responder a: <[email protected]>
Fecha: viernes, 18 de agosto de 2017, 16:19
Para: Lee Howard <[email protected]>, "[email protected]"
<[email protected]>
CC: "[email protected]" <[email protected]>, JACQUENET Christian
IMT/OLN <[email protected]>, "Senthil Sivakumar (ssenthil)"
<[email protected]>, Qin Wu <[email protected]>, "[email protected]"
<[email protected]>
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:[email protected]] De la part de
> [email protected]
> Envoyé : vendredi 18 août 2017 15:46
> À : [email protected]
> Cc : [email protected]; 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 : [email protected] [mailto:[email protected]]
> > Envoyé : vendredi 18 août 2017 15:31
> > À : BOUCADAIR Mohamed IMT/OLN; Senthil Sivakumar; JACQUENET Christian
> > IMT/OLN; [email protected]; 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
> [email protected]
> 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.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
