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

[Mark Smith <[e-mail]>]

Hi Gyan,

On Tue, 27 Oct 2020, 14:38 Gyan Mishra, <[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.

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



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

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.


> Thanks
>
> Gyan
>
> On Mon, Oct 26, 2020 at 9:22 PM Mark Smith <[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]> 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 A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
>