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

["Xiejingrong (Jingrong)" <[e-mail]>]

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:[e-mail]] On Behalf Of Gyan Mishra
Sent: Wednesday, October 28, 2020 6:10 AM
To: Mark Smith <[e-mail]>
Cc: Greg Mirsky <[e-mail]>; Jeff Tantsura <[e-mail]>; v6ops list <[e-mail]>
Subject: Re: [v6ops] draft-smith-v6ops-larger-ipv6-loopback-prefix-04

Hi Mark

Thanks for a lot of very good points and ideas!


On Tue, Oct 27, 2020 at 5:42 PM Mark Smith <[e-mail]<mailto:[e-mail]>> wrote:
Hi Gyan,
On Tue, 27 Oct 2020, 14:38 Gyan Mishra, <[e-mail]<mailto:[e-mail]>> 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.

Using link-locals would be the better option.

   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 <[e-mail]<mailto:[e-mail]>> wrote:
Hi Gyan,

Sorry not to get back to you sooner.

On Tue, 20 Oct 2020 at 00:26, Gyan Mishra <[e-mail]<mailto:[e-mail]>> 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.


>
> Thanks
>
> Gyan
>
> Sent from my iPhone
--

[图像已被发件人删除。]<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