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

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

I also share bad feelings here ...

Do it natively with IPv6, no mappings, nothing strange. It will also make possible for existing hardware, to do offload in the chipsets, which I don't think you're considering.

I also feel really weird that you are writing Ipv6 instead of IPv6, no reason for that.

If you're intending to talk about an "internal" address, use "internal" not private, please.

Regards,
Jordi
 
 

-----Mensaje original-----
De: Int-area <[e-mail]> en nombre de Fred Baker <[e-mail]>
Fecha: lunes, 5 de noviembre de 2018, 13:08
Para: Linda Dunbar <[e-mail]>
CC: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Asunto: Re: [Int-area] 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 <[e-mail]> 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:[e-mail]] On Behalf Of tom petch
    > Sent: Friday, November 02, 2018 11:26 PM
    > To: Joel Jaeggli <[e-mail]>
    > Cc: [e-mail]
    > Subject: Re: registering tunnel types
    > 
    > ---- Original Message -----
    > From: "Joel Jaeggli" <[e-mail]>
    > To: "tom petch" <[e-mail]>
    > Cc: <[e-mail]>; <[e-mail]>; "Alexandre Petrescu" <[e-mail]>
    > Sent: Tuesday, October 30, 2018 8:23 PM
    > 
    > > On Oct 30, 2018, at 05:07, tom petch <[e-mail]> 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:[e-mail]] De la part de Alexandre
    > > Petrescu
    > >>>> Envoyé : jeudi 25 octobre 2018 09:54 À : [e-mail] 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 [e-mail] Administrative
    > >>>>> Requests:
    > > https://www.ietf.org/mailman/listinfo/ipv6
    > >>
    > >>>> -------------------------------------------------------------------
    > -
    > >>>>>
    > >>>>
    > >>
    > >>> --------------------------------------------------------------------
    > >>>> IETF IPv6 working group mailing list [e-mail] Administrative
    > >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > >>
    > >>> --------------------------------------------------------------------
    > >>
    > >> --------------------------------------------------------------------
    > >> IETF IPv6 working group mailing list
    > >> [e-mail]
    > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > >> --------------------------------------------------------------------
    > >>
    > >
    > > --------------------------------------------------------------------
    > > IETF IPv6 working group mailing list
    > > [e-mail] <mailto:[e-mail]>
    > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > <https://www.ietf.org/mailman/listinfo/ipv6>
    > > --------------------------------------------------------------------
    > 
    > 
    > --------------------------------------------------------------------
    > IETF IPv6 working group mailing list
    > [e-mail]
    > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > --------------------------------------------------------------------
    > 
    > --------------------------------------------------------------------
    > IETF IPv6 working group mailing list
    > [e-mail]
    > 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
    
    _______________________________________________
    Int-area mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/int-area
    



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

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.