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

From: Linda Dunbar <[email-masked]>
Date: Sun, 4 Nov 2018 06:13:29 +0000

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:[email-masked]] On Behalf Of tom petch
Sent: Friday, November 02, 2018 11:26 PM
To: Joel Jaeggli <[email-masked]>
Cc: [email-masked]
Subject: Re: registering tunnel types

---- Original Message -----
From: "Joel Jaeggli" <[email-masked]<mailto:[email-masked]>>
To: "tom petch" <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>; "Alexandre Petrescu" <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, October 30, 2018 8:23 PM

> On Oct 30, 2018, at 05:07, tom petch <[email-masked]<mailto:[email-masked]>> 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:[email-masked]] De la part de Alexandre
> Petrescu
>>>> Envoyé : jeudi 25 octobre 2018 09:54 À : [email-masked]<mailto:[email-masked]> 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 [email-masked]<mailto:[email-masked]> Administrative
>>>>> Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
>>
>>>> -------------------------------------------------------------------
-
>>>>>
>>>>
>>
>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list [email-masked]<mailto:[email-masked]> Administrative
>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>
>>> --------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]<mailto:[email-masked]>
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
<https://www.ietf.org/mailman/listinfo/ipv6>
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Mon, 5 Nov 2018 13:06:44 +0700

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 <[email-masked]> wrote:
> 
> From: "Joel Jaeggli" <[email-masked]>
> To: "tom petch" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; "Alexandre Petrescu" <[email-masked]>
> > On Oct 30, 2018, at 05:07, tom petch <[email-masked]> wrote:
> >>
> >
> > Alex
> >
> >>>> Envoyé : jeudi 25 octobre 2018 09:54 À : [email-masked] Objet : Re:
> >>>> registering tunnel types
> >>>>
> >>>> Are:
> >>>> -IPv6 in UDPv4 and
> >>>>> IETF IPv6 working group mailing list [email-masked] Administrative
> >>>>> Requests:
> >>>> IETF IPv6 working group mailing list [email-masked] Administrative
> >> [email-masked]
> > [email-masked] <mailto:[email-masked]>
> [email-masked]
> [email-masked]

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

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 5 Nov 2018 10:40:36 +0000

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:[email-masked]] 
Sent: Monday, November 05, 2018 1:07 PM
To: Linda Dunbar <[email-masked]>
Cc: tom petch <[email-masked]>; Joel Jaeggli <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types

> > 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.
> 
> >>>> Existing identity 6tofour should be deprecated, if that means 
> >>>> 6to4, which is deprecated.
> >>>>
> >> - IETF IPv6 working group mailing list [email-masked] Administrative 
> > IETF IPv6 working group mailing list [email-masked] 
> > <mailto:[email-masked]> Administrative Requests: 

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

---

From: Fred Baker <[email-masked]>
Date: Mon, 5 Nov 2018 17:41:41 +0700

> On Nov 5, 2018, at 5:40 PM, Linda Dunbar <[email-masked]> wrote:
> 

There is no such thing as an IPv6 private address. I'm not sure how to respond to the question.
--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 5 Nov 2018 10:44:05 +0000

Fred, 

How does my phone (being IPv6 address) communicate with a web server that is IPv4 public address? 

Linda

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 5 Nov 2018 11:52:04 +0000

In SD-WAN ctxt, to let a site which has IPv4 on the WAN talk to another site which has  IPv6 on the WAN, we will need to send the packets to a device who can map the v4 address to a v6 address (no NAT, but mapped I call it). The mapping table has nothing to do with NAT and is setup by a controller in most solutions.

Now this is working irrespective if the v4 site is NATed  (one way or another) or not.

On 05/11/2018, 17:42, "Idr on behalf of Fred Baker" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 5 Nov 2018 16:23:16 +0000

So we need to add another type to the subTLV: Mapping (for the scenario of CPE using IPv6, being translated to IPv4 to connect to its peer that uses IPv4, correct?

Linda

---

From: Gert Doering <[email-masked]>
Date: Mon, 5 Nov 2018 17:59:59 +0100

Hi,

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

Since there are no private IPv6 addresses, no.

Generally speaking, if CPE1 has only IPv6 addresses and CPE2 has only
an IPv4 address, the answer is no as well, unless there is a NAT64 
involved somewhere.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 6 Nov 2018 01:06:52 +0000

Even a NAT64 is not needed. What we do now is we go to a GW (lets call it like this for now) and the GW rewrites the outer header of the tunnel srcIP and dstIP from v4 to v6 or vice versa. It is kind of decap/encap operation on the outer header as if you terminate the tunnel and reinitiate the tunnel. No NAT64 required.

On 06/11/2018, 00:00, "Idr on behalf of Gert Doering" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    
    
    Gert Doering
            -- NetMaster

    _______________________________________________
    Idr mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/idr

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 6 Nov 2018 01:08:04 +0000

The semantics on how to handle this is a different discussion. I believe the basic operation needs to be understood first. After we can see how this should be signaled.

On 05/11/2018, 23:23, "Linda Dunbar" <[email-masked]> wrote:

    Linda

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 06 Nov 2018 11:08:04 +0700

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 <[email-masked]> en nombre de Fred Baker <[email-masked]>
Fecha: lunes, 5 de noviembre de 2018, 13:08
Para: Linda Dunbar <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: Re: [Int-area] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types

    

    
    _______________________________________________
    Int-area mailing list
    [email-masked]
    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.

---

From: Gert Doering <[email-masked]>
Date: Tue, 6 Nov 2018 08:52:59 +0100

Hi,

> Even a NAT64 is not needed. What we do now is we go to a GW (lets call it like this for now) and the GW rewrites the outer header of the tunnel srcIP and dstIP from v4 to v6 or vice versa. It is ki…

So how exactly is this different from a NAT64?

"You take off the IPv4 header, put on an IPv6 header, and remember where
the response packets needs to be sent to"

If you preconfigure the mapping, it's still a NAT64 :-)

Gert Doering
        -- NetMaster

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 06 Nov 2018 15:03:04 +0700

I guess they are missing that this is an stateless NAT64 ?

Regards,
Jordi

-----Mensaje original-----
De: Int-area <[email-masked]> en nombre de Gert Doering <[email-masked]>
Fecha: martes, 6 de noviembre de 2018, 14:54
Para: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Gert Doering <[email-masked]>
Asunto: Re: [Int-area] [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types

    Hi,

    

    Gert Doering
            -- NetMaster

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 6 Nov 2018 08:22:49 +0000

We don’t perform any NAT operation. Let's first discuss the encapsulation:
In SD-WAN there is an IP tunneling of some sort (there are several options but not relevant here). So we have an inner payload which can be v4 or v6 and goes end to end, the inner payload is encapsulated in an outer IP tunnel.

So what happens is the following. I make abstraction of inner payload

SD-WAN CPE2 (v4)
SD-WAN CPE1 (v4) <----------- v4 ---------> GW <-----------------v6 ------------- > SD-WAN CPE3(v6).

Upstream traffic from SD-WAN CPE1
src-ip v4: A1, dst-IP v4 B1 ---------------> mapping < src-Ip v6: C1, dst-ip v6 D1 -----> 

Upstream traffic from SD-WAN CPE2
src-ip v4: A2, dst-IP v4 B1 ---------------> mapping < src-Ip v6: C1, dst-ip v6 D1 ----->

So irrespective of which src-CPE 1 or 2 is sending to the v6 SD-WAN CPE3 will use the same src/dst v6 address

With NAT64 even stateless the src-IP or src-port will be different to ensure you can map the reverse.
This is also used to map private IPv4 to public Ipv4, etc and many other operations.

On 06/11/2018, 14:53, "Gert Doering" <[email-masked]> wrote:

    Hi,

    

    Gert Doering
            -- NetMaster

---

From: "Yutianpeng (Tim)" <[email-masked]>
Date: Tue, 6 Nov 2018 11:23:29 +0000

Hi,
Are you using RFC 6052 only to embed ipv4 into ipv6 only or also using MAP-T (rfc7599).
I guess is only RFC6052 right?
Let's refer to RFC to have a better understanding.
Thanks
Tim

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
Sent: 06 November 2018 08:23
To: Gert Doering <[email-masked]>
Cc: [email-masked]; Fred Baker <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Idr] Using BGP to advertise SD-WAN tunnels end point's private IPv6 addresses. (was registering tunnel types

SD-WAN CPE2 (v4)

    Hi,

    

    Gert Doering
            -- NetMaster