Re: [spring] 64-bit locators

[Gyan Mishra <[e-mail]>]

On Fri, Dec 27, 2019 at 7:56 PM Mark Smith <[e-mail]> wrote:

> On Sat, 28 Dec 2019 at 09:45, Robert Raszuk <[e-mail]> wrote:
> >
> > Hi Mark,
> >
> > Happy New Year !
> >
> >>
> >> The key point is that RIDs look like IPv4 addresses, but are not. They
> only have adopted the formatting convention of IPv4 addresses. They're 32
> bit quantities. They could have just as easily been formatted as 0x hex
> strings e.g. 0xffffffff for my example. Their continued use as 32 bit
> quantities and identifiers in IPv6 supporting OSPFv3 shows how decoupled
> from both IPv4 and IPv6 they are.
> >
> >
> > We are again in 100% agreement here. That was exactly my analogy to RID
> made to Ron. But on the other hand let's also recognize that this is pretty
> common to assign router_id to be yr loopback address in number of protocols.
> >
>
>
> Right. I've done that. However, it is a convention, nothing more. In
> OSPF and BGP the RID is not an IPv4 address even if it looks like one,
> and is never used as an IPv4 address.
>
> SIDs are used as IPv6 addresses. When SIDs are used as IPv6 addresses,
> they must be compliant with the IPv6 specifications.
>
>
> >>
> >> SIDs on the other hand are at some point in time used as IPv6
> destination addresses.
> >
> >
> > Well SID locators (of variable length) need to assure packet delivery to
> a segment end points. That is a subtle but very important difference.
> >
> >>
> >> That means they have to either always comply with IPv6 address
> requirements - RFC4291 - or be converted to meet IPv6 address requirements
> when they're used as IPv6 addresses (e.g. they're 64 bit quantities that
> are then used as an IPv6 Interface Identifier by prepending an IPv6
> addressing compliant /64 prefix)
> >
> >
> > IPv6 address fields are 128 bits (for good or for bad of it).
> >And there are no :: or : there to the point Alex made earlier. What
> matters is to make sure that routing prefixes deliver packets to correct
> destinations.
> >
> > I am very puzzled reading those messages what is the point regarding all
> remaining bits outside of locator ? If this is to say RFC4291 did not
> defined a SID - sure you won - game over. But at the same time I do not see
> anything in RFC4291 which would prohibit me to put any bit sequence I like
> in the remaining (least significant) bits of the address.
>
> If you limit yourself to the Interface Identifier portion of the IPv6
> address, you can encode other semantics in that portion that are
> significant to the end points. That is permitted by RFC 7136,
> "Significance of IPv6 Interface Identifiers:"
>
> "In all cases, the bits in an IID have no generic semantics; in other
>    words, they have opaque values.  In fact, the whole IID value MUST be
>    viewed as an opaque bit string by third parties, except possibly in
>    the local context."
>
> While the packet is being forwarded towards an end point, those
> end-point semantics are to be ignored, because IPv6 forwarding is
> longest match across all 128 bits:
>
> BCP 198/RFC 7608, "IPv6 Prefix Length Recommendation for Forwarding"
>

  [Gyan] The 64 bit IID has historically has been in the context of SLAAC
and various encoding mechanisms for privacy for the 64 bit IID.

For SRv6 SID prefix,  since this would be a manual allocation by the
operator, it would fall under manual vlsm IPv6 addressing. The caveat there
is the current  IPv6 specification does not define the SID IPv6 addressing
format for locator;func;arg

So I think this new manual IPv6 addressing schema for SID has to be now
defined in the IPv6 specification.


>
>
> Regards,
> Mark.
>
>
> >And I think this is the crux of the little discussion here.
> >
>
>
>
>
>
> > Cheers,
> > R.
> >
> >
> >
> >
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: [phone]

Email: [e-mail]

www.linkedin.com/in/networking-technologies-consultant