Re: [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types

Fred, 

Thank you very much for the comments. 

Questions to you: 

If a CPE-1 has private IPv6 addresses for its ports behind NAT, and CPE-2 has IPv4 address, can CPE-1 communicate with CPE-2 by the NAT's IPv4 address? 

Linda

-----Original Message-----
From: Fred Baker [mailto:fredbaker.ietf@gmail.com] 
Sent: Monday, November 05, 2018 1:07 PM
To: Linda Dunbar <linda.dunbar@huawei.com>
Cc: tom petch <ietfc@btconnect.com>; Joel Jaeggli <joelja@bogus.com>; idr@ietf.org; int-area@ietf.org; ipv6@ietf.org
Subject: Re: Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types

Linda, I see a couple of issues here. Speaking as an individual.

First, IPv6 doesn't have private addresses, and in the general case doesn't use NATs. There is no direct counterpart to RFC 1918. The nearest parallel might be a ULA (RFC 4193), but they are by design not routable using BGP.

Second, yes NAT64 technology exists, but from a routing perspective the endpoint either has an IPv4 address or an IPv6 address, not an IPv6 address that is translated into an IPv4 address. That concept doesn't exist in routing.

> On Nov 4, 2018, at 1:13 PM, Linda Dunbar <linda.dunbar@huawei.com> wrote:
> 
> https://datatracker.ietf.org/doc/draft-dunbar-idr-bgp-sdwan-overlay-ext/ specifies a new BGP SAFI (=74) in order to advertise a SD-WAN edge node’s capabilities in establishing SD-WAN overlay tunnels with other SD-WAN nodes through third party untrusted networks.
> 
> Since a SD-WAN end point might use IPv6 private address, which is translated to IPv4 public address via NAT,  want to get IPv6 group & Inter Area WG feedback on the subTLV proposed in the draft:
> 
> EncapsExt sub-TLV is for describing additional information about the SD-WAN tunnel end-points, such as NAT property. A SD-WAN edge node can inquire STUN (Session Traversal of UDP Through Network Address Translation RFC 3489) Server to get the NAT property, the public IP address and the Public Port number to pass to peers.
> 
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |EncapExt Type  |  EncapExt subTLV Length       |I|O|R|R|R|R|R|R|
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     | NAT Type      |  Encap-Type   |Trans networkID|     RD ID     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                Private  IP Address                            |
>             32-bits for IPv4, 128-bits for Ipv6
>                     ~~~~~~~~~~~~
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                Private  Port                                  |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                Public IP                                      |
>             32-bits for IPv4, 128-bits for Ipv6
>                     ~~~~~~~~~~~~
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                Public Port                                    |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Where:
> o       EncapExt Type: indicate it is the EncapExt SubTLV.
> o       EncapExt subTLV Length: the length of the subTLVE.
> o       Flags:
> o       I bit: if set to 0, indicate the private address is IPv4. If set to 1, it indicates the private address is IPv6.
> o       O bit: if set to 0, indicate the public address is IPv4. If set to 1, it indicates the public address is IPv6.
> o       R bits: reserved for future use. Must be set to 0 now.
> 
> o       NAT Type：without NAT; 1:1 static NAT; Full Cone; Restricted Cone; Port Restricted Cone; or Symmetric
> o       Encap Type：SD-WAN tunnel encapsulation types, such as IPsec+GRE, IPsec+VxLAN, IPsec without GRE, GRE (when tunnel is over secure underlay network)
> o       Transport Network ID：Central Controller assign a global unique ID to each transport network；
> o       RD ID：Routing Domain ID，Need to be global unique.
> o       Private IP：The local IP address of the tunnel end-point；
> o       Private Port：used by Remote SD-WAN node for establishing IPsec to this specific port.
> o       Public IP：The IP address after the NAT.
> o       Public Port：The Port after the NAT.
> 
> 
> Thank you very much for feedback.
> 
> Linda Dunbar
> 
> 
> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of tom petch
> Sent: Friday, November 02, 2018 11:26 PM
> To: Joel Jaeggli <joelja@bogus.com>
> Cc: ipv6@ietf.org
> Subject: Re: registering tunnel types
> 
> ---- Original Message -----
> From: "Joel Jaeggli" <joelja@bogus.com>
> To: "tom petch" <ietfc@btconnect.com>
> Cc: <mohamed.boucadair@orange.com>; <ipv6@ietf.org>; "Alexandre 
> Petrescu" <alexandre.petrescu@gmail.com>
> Sent: Tuesday, October 30, 2018 8:23 PM
> 
> > On Oct 30, 2018, at 05:07, tom petch <ietfc@btconnect.com> wrote:
> >>
> >
> > Alex
> >
> > I agree, at least in part; tunnels and interfaces are different
> animals
> > and it is unfortunate that they were conflated in SMI.
> >
> > I was surprised that NETMOD had not produced a YANG module for 
> > tunnels but it seems that there has been no need for the past 
> > decade.  That said, I think that it is a good idea to have one.  
> > Whether or not it should mirror the Tunnel MIB I find more debatable.
> 
> It’s not entirely obvious to me that netted / netconfig would be where the tunnel models were produced.
> 
> They tend if fact to be produced by the tunnel protocol maintainers e.g.
> l3sm/l2sm/ccamp and so on. The management tools for a product tend to be developed itself in my experience.
> 
> <tp>
> 
> Joel
> 
> My concern is that something that cuts across a number of IETF WG should get adequate review.  The YANG interface module was much discussed in the netmod WG, with an existing MIB as guidance, before becoming an RFC.
> 
> The proposed YANG tunnel module, which borrows the concepts of the interface module, that additions should be made by the Tunnel MIB Designated Expert to a registry and then propagated to the Tunnel MIB and the Tunnel YANG module, has not been discussed in any WG.  The proposal, as I mentioned before, has been added to the I-D after IETF Last Call has been completed so appears to me to be the work of one individual, without any review; the I-D lists seven editors, six of whom appear to be absent.  TheWG mailing list seems devoid of any discussion.
> 
> I believe that the IETF succeeds because of peer review, and I struggle to see that here.
> 
> Tom Petch
> 
> > My own homework came across other IP in IP varieties which do not 
> > appear.
> >
> > Tom Petch
> >
> >
> >>
> >> Alex
> >>
> >>>
> >>> If you need a new value or if you have a question about a given
> > interface tunnel type, please follow the guidelines in the url cited 
> > above. All this is out of the scope of draft-ietf-softwire-yang.
> >>>
> >>> Cheers,
> >>> Med
> >>>
> >>>> -----Message d'origine-----
> >>>> De : ipv6 [mailto:ipv6-bounces@ietf.org] De la part de Alexandre
> > Petrescu
> >>>> Envoyé : jeudi 25 octobre 2018 09:54 À : ipv6@ietf.org Objet : Re:
> >>>> registering tunnel types
> >>>>
> >>>> Are:
> >>>> -IPv6 in UDPv4 and
> >>>> -IPv6 in IPv6 as used by openvpn;
> >>>>
> >>>> covered by the list below?
> >>>>
> >>>> These are a few tunnelling mechanisms I use routinely.
> >>>>
> >>>> Existing identity 6tofour should be deprecated, if that means 
> >>>> 6to4, which is deprecated.
> >>>>
> >>>> Existing identity iphttps has a version number for IP?
> >>>>
> >>>> Alex
> >>>>
> >>>> Le 24/10/2018 à 17:57, tom petch a écrit :
> >>>>> draft-ietf-softwire-yang
> >>>>> completed IETF Last Call two weeks ago and, since then, has
> > acquired a
> >>>>> YANG module that defines tunnel types, as listed below.  It is
> > intended
> >>>>> to be a IANA-maintained module and so changes to the list of
> > tunnels
> >>>>> will not require a reissue of the softwires RFC-to-be.  At the
> > same
> >>>>> time, getting it right first time never did any harm so if 
> >>>>> anyone
> > can
> >>>>> think of any missing, or can think of other places where there
> > might be
> >>>>> other tunnels lurking, now would be a good time to mention it.
> >>>>>
> >>>>> It is based on RFC4087 Tunnel MIB (which created an SMI Textual 
> >>>>> Convention that went up to Teredo) so tunnels from that vintage
> > are
> >>>>> likely well catered for.  softwires is not where I would have
> > first
> >>>>> looked for tunnel types, but it has a certain logic to it.
> >>>>>
> >>>>>       identity  other
> >>>>>
> >>>>>       identity direct
> >>>>>
> >>>>>       identity gre
> >>>>>
> >>>>>       identity minimal
> >>>>>
> >>>>>       identity l2tp
> >>>>>
> >>>>>       identity pptp
> >>>>>
> >>>>>       identity l2f
> >>>>>
> >>>>>       identity udp
> >>>>>
> >>>>>       identity atmp
> >>>>>
> >>>>>       identity msdp
> >>>>>
> >>>>>       identity sixtofour
> >>>>>
> >>>>>       identity sixoverfour
> >>>>>
> >>>>>       identity isatap
> >>>>>
> >>>>>       identity teredo
> >>>>>
> >>>>>       identity iphttps
> >>>>>
> >>>>>       identity softwiremesh
> >>>>>
> >>>>>       identity dslite
> >>>>>
> >>>>>       identity  aplusp
> >>>>>
> >>>>> Tom Petch
> >>>>>
> >>
> >>>> -----------------------------------------------------------------
> >>>> --
> -
> >>>>> IETF IPv6 working group mailing list ipv6@ietf.org 
> >>>>> Administrative
> >>>>> Requests:
> > https://www.ietf.org/mailman/listinfo/ipv6
> >>
> >>>> -----------------------------------------------------------------
> >>>> --
> -
> >>>>>
> >>>>
> >>
> >>> ------------------------------------------------------------------
> >>> --
> >>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>
> >>> ------------------------------------------------------------------
> >>> --
> >>
> >> -------------------------------------------------------------------
> >> - IETF IPv6 working group mailing list ipv6@ietf.org Administrative 
> >> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> -------------------------------------------------------------------
> >> -
> >>
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list ipv6@ietf.org 
> > <mailto:ipv6@ietf.org> Administrative Requests: 
> > https://www.ietf.org/mailman/listinfo/ipv6
> <https://www.ietf.org/mailman/listinfo/ipv6>
> > --------------------------------------------------------------------
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win.
     Sun Tzu