Re: about violation of standards

[Gyan Mishra <[e-mail]>]

Alexandre, Brian & Pascal & Ole

Sorry -  I misunderstood the earlier thread subject "about violating
standard" and Alexandre's example with BSD fe80:1::1  - took me on a
tangent.  Sorry about that.

Now I think I am on board that what we are trying to do is build a new
revision for the link local addressing schema we have today and address the
pitfalls and provide improvements to help with future use cases.

After reading through the the dialog I am seeing that what we are trying to
do is develop or improve what currently is defined for link local with a
new specification or idea that provides a means of DAD that is done with
EUI64 stationid or random station id or address based algorithm that
provides for a more intuitive ULA type subnet field where the 00 -54 bits
would become legacy IPv6 and  new products deployed would be able to
support this new GULLA type local address that has global significance but
still used for local packet processing ICMPv6 Type 133/134 RA/RS & Type
135/136 NS/NA ND cache but have an ability to be dynamic algorithm that has
a DAD type capability to prevent overlap such as is done with ULA RFC 4193.

ULA provides the ability to use private non routed space similar to IPV4
RFC 6761 but then requires 6to6 NAT overload for external access which I
think in the auto use case would work so we don't burn through /48 per
manufacturer but then have the 6to6 nat overhead.

So with this new link local revision we are trying to address the pitfalls
with the current RFC 4291 RFC addressing schema for link local.  Is that
correct?

I think one of the pitfalls of the current link local fe80::/10 is it is
one big space and their is no subnet-id so I think with this new version
link local revision we would essentially use the 54 bit field as the
subnet-id using a ULA type GULLA randomness in assigning.   In most cases
the fe80::/10 is fine and using the EUI64 for unique station-id but I guess
if you want to build more meaning into the link local I can now see adding
a new subnet-id field for the new link local revision does make sense.


Below is from RFC 4291 - ULA - so I guess we are thinking the subnet-id
would have a similar GULLA randomness built in to ensure uniqueness.  Makes
sense.

3.2.1 <https://tools.ietf.org/html/rfc4193#section-3.2.1>.  Locally
Assigned Global IDs

   Locally assigned Global IDs MUST be generated with a pseudo-random
   algorithm consistent with [RANDOM
<https://tools.ietf.org/html/rfc4193#ref-RANDOM>].  Section 3.2.2
<https://tools.ietf.org/html/rfc4193#section-3.2.2> describes a
   suggested algorithm.  It is important that all sites generating
   Global IDs use a functionally similar algorithm to ensure there is a
   high probability of uniqueness.

   The use of a pseudo-random algorithm to generate Global IDs in the
   locally assigned prefix gives an assurance that any network numbered
   using such a prefix is highly unlikely to have that address space
   clash with any other network that has another locally assigned prefix
   allocated to it.  This is a particularly useful property when
   considering a number of scenarios including networks that merge,
   overlapping VPN address space, or hosts mobile between such networks.




>From that angle of improvement the 54 bit all 0's field does seem like a
waste being all 0's and maybe the original author back in 1998 meant that
was for the "now" almost 20 years ago but was meant to keep open for future
change and uses cases.  Understood and that makes sense.

While we are looking at improvement of the link local address and
addressing pitfalls I was wondering if this maybe another change we could
make to the link local addressing structure.

So IGP routing protocols such as ISIS & OSPF use the Link Local as the next
hop which is not intuitive having the EUI64 station-id which I understand
that was done to maintain uniqueness.  What if we did something similar to
a GULLA randomness with the station-id so that it is not MAC based.

In implementations I have worked with to make the next hop more intuitive
where we have an IPv6 address on the routed interface and not just the link
local we have embedded the LSB bits excluding the 1st 16 bits into the
station-id to make it similar to the global unicast address assigned to the
routed interface.  For a routed interface you don't necessarily have to
have a IPv6 address and there are Cisco and other vendor implementations
that have a Cisco like knob "ipv6 enable" which enables IPv6 packet
processing so you don't have to assign a IPv6 address.  However in IPv6
implementations I have worked with we have done so, so that when you
traceroute  you can see global unicast addresses along the routed next hops
hop by hop along the path for ease of troubleshooting and MTTR in cases of
failures or routing issues.

I wonder if this is something we can do to improve on with the current
standard EUI64 or random station-id used for the link local address today.

Thank you

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 7:22 PM Brian E Carpenter <
[e-mail]> wrote:

> On 23-Apr-19 22:36, Ole Troan wrote:
> > Pascal,
> >
> > Sounds like what you want is to replace link-local addresses with ULAs.
>
> No, because ULAs have a different constraint: they are valid within a
> specific domain, which we assume to be relatively stable, so that its
> border routers can filter the ULA prefix. What Pascal describes is a much
> more fluid situation, where link-local domains are forming and dissolving
> all the time and unpredictably. (Exactly the OCB situation in heavy
> traffic, in fact.)
>
> > I’m quite convinced that the complexity tradeoff of that scheme is much
> worse than having to deal with scoped addressed. ;-)
>
> It is. Mesh networks are not easy, especially with other SDOs trying to
> solve mesh network problems at layer 2. This discussion is at layer 2.5.
> But I think Pascal is correct to say "nodes may need to form new LLAs to
> talk to one another and the scope where LLA uniqueness can be dynamically
> checked is really that pair of nodes." How can GUA routing be stable in
> such a network?
>
>     Brian
>
>    Brian
>
> > Cheers,
> > Ole
> >
> >> On 23 Apr 2019, at 12:19, Pascal Thubert (pthubert) <[e-mail]>
> wrote:
> >>
> >>
> >>>> Some functions in the router are complex to implement because same
> value
> >>> for a link local address appears on multiple interfaces.
> >>>
> >>> Like what?
> >>
> >> Like structuring the tables where you maintain the address binding.
> >>
> >> Because a link local is only unique within the link / broadcast domain
> where DAD occurs, you have to add the sense of that link / broadcast domain
> as an additional key to your binding table, whereas for the GUA the prefix
> gives you that from within the address, and the address is sufficient as a
> key.
> >>
> >> Turns out nothing is too particularly neat for the role. On Ethernet, a
> VLAN does not guarantee a unique global value though at least it is a local
> sense of the broadcast domain and you can use it as a node-local key. But
> you cannot get a global sense of where the link local address is in your
> network by just looking at it.
> >>
> >> If there was an encoding of that global sense of the broadcast domain
> in the link local address, one could log in or even send a message to any
> router in that domain and ask if the link local is live by making it ping
> or what. And one could generate that request using the link local address
> only, as opposed to encoding a address%interface that is locally
> significant to the particular router or host that I'd use to ping the link
> local address, always a hassle.
> >>
> >> This would extend the value of the link local without changing its
> scope, and enable common APIs, tables and GUIs, understanding that what
> we'd encode represents a physical domain that is not necessarily mapped to
> a logical subnet.
> >>
> >>
> >>>> 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?
> >>
> >> Not of a subnet, rather an ID for a link or a broadcast domain, a bit
> like what DNA was after. On an Ethernet domain it is easy to confuse those
> things because the shared wiring defines at the same time the physical
> link, the broadcast domain and the subnet that we map over it. But the
> difference shows on legacy NBMA like ATM or FR, on shared links and on
> newer types of NBMA such as radio and composite radio-wires networks.
> >>
> >> In radios, the broadcast domain is defined differently by each
> transmitter as opposed to defined commonly by a shared wire.
> >> In mesh-under (e.g., a Wi-Fi mesh or IEEE 802.15.10) the link extends
> beyond the broadcast domain. In route-over (e.g., 6TiSCH with RPL), the
> subnet extends beyond the link.
> >> Note that a Wi-Fi BSS is an exception whereby the broadcast domain of
> the AP emulates the common wire, but that takes a particular L2 emulation
> that is not present in other types of WPAN/WLAN/LPWAN radio links.
> >>
> >> On radios without a BSS, links between peers come and go as their
> individual broadcast domains meet physically. The ND DAD operation cannot
> provide once and for all guarantees on the broadcast domain defined by one
> radio transmitter if that transmitter keeps meeting new peers on the go.
> The nodes may need to form new LLAs to talk to one another and the scope
> where LLA uniqueness can be dynamically checked is really that pair of
> nodes. As long as there's no conflict a node may use the same LLA with
> multiple peers but it has to revalidate DAD very time. So it's like if each
> pair of nodes defines a temporary P2P link, like a sub-interface of the
> radio interface. In that case, we could encode something about that P2P
> link in the LLA, like something derived from MAC addresses, while keeping
> the same IID.
> >>
> >> All the best,
> >>
> >> Pascal
> >>
> >>> -----Original Message-----
> >>> From: ipv6 <[e-mail]> On Behalf Of Ole Troan
> >>> Sent: mardi 23 avril 2019 09:33
> >>> To: Pascal Thubert (pthubert) <[e-mail]>
> >>> Cc: Fernando Gont <[e-mail]>; Alexandre Petrescu
> >>> <[e-mail]>; 6man WG <[e-mail]>; 神明達哉
> >>> <[e-mail]>
> >>> Subject: Re: about violation of standards
> >>>
> >>>> Some functions in the router are complex to implement because same
> value
> >>> for a link local address appears on multiple interfaces.
> >>>
> >>> Like what?
> >>>
> >>>> 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?
> >>>
> >>> Ole
> >>> --------------------------------------------------------------------
> >>> 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
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> 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