Re: Globally Unique Link Local Addresses (Re: about violation of standards)

[Gyan Mishra <[e-mail]>]

Hi Brian

I think the LULLA or GULLA would work as the uniqueness would come from the
station-id not from the subnet-id field that is using the LULLA style
algorithm which is not bullet proof for uniqueness and is based on
probability.

I am guessing what the LULLA would provide is a means to better manage the
fe80::/10 space being subnetted even though still "non routable" as  the
1st 10 bits being fe80 the subnet-id even if that were changed would not
make it even locally routable so it that it would be bleed out into the
network even locally.

This new version of the link local adress would still be "non routable".


Gyan S. Mishra
IT Network Engineering & Technology Consultant
Routing & Switching / Service Provider MPLS & IPv6 Expert
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Mobile – 202-734-1000
On Tue, Apr 23, 2019 at 11:29 PM Mark Smith <[e-mail]> wrote:

> Hi Brian,
>
> On Wed, 24 Apr 2019 at 07:52, Brian E Carpenter
> <[e-mail]> wrote:
> >
> > Firstly, I don't believe they could in any sense be globally unique.
> > (Even ULAs don't claim to be mathematically unique, just probably
> unique.)
> > So let's call them LULLAs (Locally Unique...), a.k.a. Lullabies.
> >
>
> Agree, was really only adding the Global in there as more of a goal
> rather than a fact or guarantee and as a more pronounceable acronym.
>
> I think "ULA" suffers from a bit of ambiguity too to get brevity.
>
> > However:
> >
> > > however it would be simpler for applications to not have to special
> case Link-Local addresses and use sin6_scope_id.
> >
> > But they have to anyway, because you can't know in the general case
> whether LULLAs are in use or not. Anyway, there's nothing new about needing
> to store an
> > interface index number (or name) with an LL address. Any existing code
> that
> > is LL-dependent already does this, unless it's broken.
> >
>
> I think the advantage of LLs is that they're required on all IPv6
> enabled interfaces, so there is always an IPv6 address available for
> an application (and other things) to use.
>
> However, the drawback of using LL addresses is that each application
> has to be written to specifically handle them via sin6_scope_id.
>
> Ideally, applications wouldn't have to be written to specially handle
> link-local scope addresses. Some type of link-local scope addresses
> with some link-attached nodes agreed unique Subnet ID would facilitate
> that, pushing the issue of interface selection down into each node's
> route table. All applications would then inherently support the use of
> these link-local scope addresses.
>
> I understand that one of the motivations for Link-Local addressing was
> the "dentist's office" scenario i.e. non-technical, plug and play, "it
> just works" networking. Having to have specially adapted applications
> to suit that that scenario is pretty contradictory to that goal.
>
>
> The scheme I've suggested below could work with the ULA address space.
> The only real difference is that packets with Link-Local addresses are
> formally prohibited from being forwarded off of the link, which could
> provide a useful security benefit to certain applications, although we
> know they do leak on occasion. With the ULA address space, off link
> forwarding of course it isn't prohibited, so it's a specific risk if
> the ULA address space was used.
>
> Regards,
> Mark.
>
>
>
>
>
>
> > Regards
> >    Brian
> >
> > On 23-Apr-19 21:57, Mark Smith wrote:
> > >
> > >
> > > On Tue., 23 Apr. 2019, 17:33 Ole Troan, <[e-mail] <mailto:
> otroan@employees..org>> wrote:
> > >
> > >     > Some functions in the router are complex to implement because
> same value for a link local address appears on multiple interfaces.
> > >
> > >     Like what?
> > >
> > >
> > >
> > > I don't specifically know about complex to implement router functions,
> however it would be simpler for applications to not have to special case
> Link-Local addresses and use sin6_scope_id.
> > >
> > >
> > >     > It would be useful to be able to encode an abstract interface ID
> somewhere in the /64. Legacy 00 would mean unspecified...
> > >
> > >     Sounds like you need subnet-id election?
> > >
> > >
> > > Here's how I've thought you could do it for quite a while.
> > >
> > > I've thought the best idea would be to have a subnet ID that is
> generated using the same/similar algorithm ULAs are generated with, to try
> to avoid subnet ID collision across links attached to interfaces on the
> same multihomed host or router.
> > >
> > > A name could be Globally Unique Link Local Addresses (GULLAs) or
> Unique Link Local Addresses (ULLAs). (I'd think the first, just because its
> a more easily pronounceable word.)
> > >
> > > 1. First node on the link looks at the RAs that it receives due to its
> RSes.
> > >
> > > 2. If none of them have a PIO for a subnet within the GULLA aggregate
> prefix (which may be fe80::/10), it generates a subnet ID per the ULA
> algorithm, resulting in the link's GULLA Subnet Prefix.
> > >
> > > 3. The node starts advertising RAs containing the GULLA Subnet PIO. If
> the node is a host, the Router Lifetime is 0. The GULLA Subnet PIO
> lifetimes are not Infinite, unlike the lifetimes for the traditional LL
> prefix and addresses. Lifetimes in this PIO probably should be the RFC 4861
> defaults. (If the node is also a router, it would advertise any other PIOs
> in the same RA, with a non-zero router life time if it is a default router.)
> > >
> > > 4. Second node on the link, due to its RSes, would see that another
> node is already announcing a GULLA Subnet PIO in one of the received RAs.
> > >
> > > 5. Second node starts also issuing RAs also containing the GULLA
> Subnet PIO. Again, if the node is a host, RA router lifetime of zero.
> > >
> > > 6. 3rd and subsequent nodes attached to the link have some sort of
> election or selection algorithm to determine which one or ones take over if
> the first or both nodes stop issuing periodic RAs containing the GULLA
> Subnet PIO.
> > >
> > > Ideally it would be good to have non-GULLA nodes also learn and use
> this new GULLA Subnet, learning it from the GULLA RA announcing nodes.
> However, that would mean that the fe80::/10 prefix couldn't be used,
> because per-RFC4861, nodes are to ignore RA PIOs for the Link-Local prefix.
> So the GULLA aggregate prefix would have to be outside of fe80::/10.
> > >
> > > The above is mostly inspired by very distant memories of how Appletalk
> seed routers work to convey cable range (network prefix) information to
> other Appletalk routers on the link.
> > >
> > > Regards,
> > > Mark.
> > >
> > >
> > >
> > >
> > >
> > >     Ole
> > >
>  --------------------------------------------------------------------
> > >     IETF IPv6 working group mailing list
> > >     [e-mail] <mailto:[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
> --------------------------------------------------------------------
>


-- 
Gyan S. Mishra
IT Network Engineering & Technology Consultant
Routing & Switching / Service Provider MPLS & IPv6 Expert
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Mobile – 202-734-1000