Subject: [v6ops] draft-smith-v6ops-larger-ipv6-loopback-prefix-04

From: Gyan Mishra <[email-masked]>
Date: Mon, 19 Oct 2020 09:26:41 -0400

Hi Mark

What ended up happening with this draft and was the work picked up in any other draft.

Thanks 

Gyan

Sent from my iPhone

---

From: Mark Smith <[email-masked]>
Date: Tue, 27 Oct 2020 12:21:40 +1100

Hi Gyan,

Sorry not to get back to you sooner.

On Tue, 20 Oct 2020 at 00:26, Gyan Mishra <[email-masked]> wrote:
>
>
> Hi Mark
>
> What ended up happening with this draft

I let it expire, as I didn't think it would be adopted by the WG.

There seemed to be a bit of resistance to it as people said that ULAs
could be used instead.

The link local prefix is also required on any IPv6 interface, per
RFC4291, so there is supposed to be a link-local /64 on the loopback
interface(s) providing many addresses to which a process could be
separately bound, although a drawback of using the link-local prefix
is having to deal with scope/zone IDs (although Linux doesn't comply
with that requirement, it doesn't have a link-local address on the
loopback interface by default).

> and was the work picked up in any other draft.

Not as far as I'm aware.

What is your use case?

Regards,
Mark.

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 26 Oct 2020 23:38:44 -0400

Hi Mark

Thanks for responding.

The use case was for BFD continuity test for special use cases or MPLS lsp
ping and now draft for  vxlan BFD, where for IPv4 for continuity test you
have 127/8 loopback but for IPv6 there is only one loopback address ::/128.

For IPv6 we ended up using IPv4 mapped IPv6 addresses for MPLS LSP ping
used to bootstrap to FEC LSP ping to BFD.  So now for new vxlan BFD the
topic came up and again for another draft which now as a standard we are
now planning to use IPv4 mapped IPv6 for BFD continuity test.

That BFD thread brought back the IPv6 RFC 4291 standard that IPv6 only has
one loopback where IPv4 has a /8 worth.

As you stated per RFC 4291, there is supposedly a link local /64 fe80::/64
loopback on the loopback interface which has plenty of space.  I have to
check on a router but I am guessing If that is implemented by all router
vendors following RFC 4291, then that would be an alternative option to
IPv4 mapped IPv6 for BFD continuity tests.

Thanks

Gyan

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Mark Smith <[email-masked]>
Date: Wed, 28 Oct 2020 08:42:41 +1100

Hi Gyan,

> now planning to use IPv4 mapped IPv6 for BFD continuity test.

I think it would be better to come up with a native IPv6 method rather than
importing IPv4 addresses into IPv6 just to get the capability you need.

Ultimately I think an IPv6 only network should have no IPv4 in it at all,
including no IPv4 mapped addresses.

> IPv4 mapped IPv6 for BFD continuity tests.

Using link-locals would be the better option.

If you need to encode special forwarding handling, other than standard
unicast forwarding, then I think a special well known prefix e.g. an IANA
assigned/64 or /48 for this purpose would be the best option.

There are already a number of IPv6 examples where special forwarding rules
are defined for a well known prefix - link-local address space, the
ff00::/8 multicast address space, and the RFC6666 discard prefix.

Regards,
Mark.

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 27 Oct 2020 18:10:24 -0400

Hi Mark

Thanks for a lot of very good points and ideas!

On Tue, Oct 27, 2020 at 5:42 PM Mark Smith <[email-masked]> wrote:

>> The use case was for BFD continuity test for special use cases or MPLS
>> lsp ping and now draft for  vxlan BFD, where for IPv4 for continuity test
>> you have 127/8 loopback but for IPv6 there is only one loopback address
>> ::/128.
>>
> I think it would be better to come up with a native IPv6 method rather
> than importing IPv4 addresses into IPv6 just to get the capability you need.
>

    Gyan> I was thinking the same about the very very soon eventual IPv6
only core transports.  I have a draft in BESS WG that I am presenting at
IETF 109 that is based on RFC 6555 softwire mesh framework basically 4 edge
over a v6 only core which using RFC 5549 next hop encoding we can eliminate
for operators all IPv4 peering down that it IPv4 AFI NLRI  is stacked on
top of IPv6 BGP peer.  With that model IPv4 would be 100% eliminated from
the core transport.  The BFD continuity test is on the core transport so I
definitely can see the downside of IPv4 mapped IPV6 when IPV4 is eliminated
from the core.  I don’t think we want any IPv6 being underpinned by IPv4
which is what happens with doing the IPv4 mapped IPv6.

> including no IPv4 mapped addresses.

Gyan> Agreed

>
>
>
>> That BFD thread brought back the IPv6 RFC 4291 standard that IPv6 only
>> has one loopback where IPv4 has a /8 worth.
>>
>> As you stated per RFC 4291, there is supposedly a link local /64
>> fe80::/64 loopback on the loopback interface which has plenty of space.  I
>> have to check on a router but I am guessing If that is implemented by all
>> router vendors following RFC 4291, then that would be an alternative option
>> to IPv4 mapped IPv6 for BFD continuity tests.
>>
>

   Gyan> Agreed

> ff00::/8 multicast address space, and the RFC6666 discard prefix.

    Gyan> That is definitely an interesting idea and I think makes sense
and viable for sure.  There maybe other use cases I am thinking out loud
maybe with BIER IPv6  MVPN and possible some other use cases.  I wonder
even for the SRv6 locator maybe having a special range outside of GUI
allocation as it has special handling with steering.

Another question related to IPv6 Anycast.  IPv6 has built in anycast
address, I believe it’s the last 7 bits subnet router Anycast address.
Since any routable prefix can be Anycasted for services proximity routing,
 what is the real use case or functionality of the IPv6 built in Anycast
/121 range.

>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
>>
>> --

*Gyan Mishra*

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Wed, 28 Oct 2020 03:49:52 +0000

Hi,
Agreed very much that larger-ipv6-loopback-prefix is useful for IPv6-only network. Thanks for digging out this …
As the draft already stated at the very beginning,  “to run multiple instances of the application using the same transport layer protocol port on the same development host.”
Also useful to eliminate the need of too many UDP ports (attack surface) opening by the various OAM tools TWAMP/STAMP/BFD/SBFD/ping/……

Regards,
Jingrong

From: v6ops [mailto:[email-masked]] On Behalf Of Gyan Mishra
Sent: Wednesday, October 28, 2020 6:10 AM
To: Mark Smith <[email-masked]>
Cc: Greg Mirsky <[email-masked]>; Jeff Tantsura <[email-masked]>; v6ops list <[email-masked]>
Subject: Re: [v6ops] draft-smith-v6ops-larger-ipv6-loopback-prefix-04

Hi Mark

On Tue, Oct 27, 2020 at 5:42 PM Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,
On Tue, 27 Oct 2020, 14:38 Gyan Mishra, <[email-masked]<mailto:[email-masked]>> wrote:

Hi Mark

Thanks for responding.

The use case was for BFD continuity test for special use cases or MPLS lsp ping and now draft for  vxlan BFD, where for IPv4 for continuity test you have 127/8 loopback but for IPv6 there is only one loopback address ::/128.

For IPv6 we ended up using IPv4 mapped IPv6 addresses for MPLS LSP ping used to bootstrap to FEC LSP ping to BFD.  So now for new vxlan BFD the topic came up and again for another draft which now as a standard we are now planning to use IPv4 mapped IPv6 for BFD continuity test.

I think it would be better to come up with a native IPv6 method rather than importing IPv4 addresses into IPv6 just to get the capability you need.

    Gyan> I was thinking the same about the very very soon eventual IPv6 only core transports.  I have a draft in BESS WG that I am presenting at IETF 109 that is based on RFC 6555 softwire mesh framework basically 4 edge over a v6 only core which using RFC 5549 next hop encoding we can eliminate for operators all IPv4 peering down that it IPv4 AFI NLRI  is stacked on top of IPv6 BGP peer.  With that model IPv4 would be 100% eliminated from the core transport.  The BFD continuity test is on the core transport so I definitely can see the downside of IPv4 mapped IPV6 when IPV4 is eliminated from the core.  I don’t think we want any IPv6 being underpinned by IPv4 which is what happens with doing the IPv4 mapped IPv6.

Ultimately I think an IPv6 only network should have no IPv4 in it at all, including no IPv4 mapped addresses.

Gyan> Agreed

That BFD thread brought back the IPv6 RFC 4291 standard that IPv6 only has one loopback where IPv4 has a /8 worth.

As you stated per RFC 4291, there is supposedly a link local /64 fe80::/64 loopback on the loopback interface which has plenty of space.  I have to check on a router but I am guessing If that is implemented by all router vendors following RFC 4291, then that would be an alternative option to IPv4 mapped IPv6 for BFD continuity tests.

   Gyan> Agreed

If you need to encode special forwarding handling, other than standard unicast forwarding, then I think a special well known prefix e.g. an IANA assigned/64 or /48 for this purpose would be the best option.

There are already a number of IPv6 examples where special forwarding rules are defined for a well known prefix - link-local address space, the ff00::/8 multicast address space, and the RFC6666 discard prefix.

    Gyan> That is definitely an interesting idea and I think makes sense and viable for sure.  There maybe other use cases I am thinking out loud maybe with BIER IPv6  MVPN and possible some other use cases.  I wonder even for the SRv6 locator maybe having a special range outside of GUI allocation as it has special handling with steering.

Another question related to IPv6 Anycast.  IPv6 has built in anycast address, I believe it’s the last 7 bits subnet router Anycast address.  Since any routable prefix can be Anycasted for services proximity routing,  what is the real use case or functionality of the IPv6 built in Anycast /121 range.

Regards,
Mark.

Thanks

Gyan

On Mon, Oct 26, 2020 at 9:22 PM Mark Smith <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

Not as far as I'm aware.

What is your use case?

Regards,
Mark.

--

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
Silver Spring, MD<https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>

--

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Mark Smith <[email-masked]>
Date: Thu, 29 Oct 2020 19:42:41 +1100

Hi Gyan,

On Wed, 28 Oct 2020, 09:10 Gyan Mishra, <[email-masked]> wrote:

> <snip>

There isn't really an IPv6 anycast range, IPv6 anycast addresses come out
of the unicast address space, and are only designated as anycast either by
announcing a "unicast" route from multiple different locations on purpose
(if it's not on purpose, it's a fault), and by configuring the host with
the anycast address to know that it is an anycast address.

I've thought that the use of Anycast would increase, and have thought that
it would be useful to have a specially designated anycast prefix. It has
also occurred to me that anycast has some of the properties of unicast as
well as some of the properties of multicast, so could be seen to fit in
between unicast and multicast (1:1 -> 1:Any -> 1:Many)

"IPv6 Formal Anycast and Functional Anycast Addresses"

IETF 106 presentation -
https://www.ietf.org/proceedings/106/slides/slides-106-6man-sessa-ipv6-formal-anycast-addresses-and-functional-anycast-addresses-00.pdf

Draft -
https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-01

Regards,
Mark.