RE: [EXTERNAL] Re: 64bit MAC addresses and SLAAC

["Pascal Thubert (pthubert)" <[e-mail]>]

> From: Fernando Gont <[e-mail]>
> Sent: jeudi 18 juin 2020 13:27
> To: Pascal Thubert (pthubert) <[e-mail]>; Templin (US), Fred L
> <[e-mail]>; Kerry Lynn <[e-mail]>
> Cc: IPv6 List <[e-mail]>
> Subject: Re: [EXTERNAL] Re: 64bit MAC addresses and SLAAC
> 
> On 18/6/20 07:58, Pascal Thubert (pthubert) wrote:
> > Hello Fernando:
> >
> >>> Note that this
> >>> looks antinomic with the spare part goal above; that would indeed be
> >>> antinomic for burn-in MAC addresses; but there are also standards
> >>> out there that use a shorter assigned MAC address, e.g., to reduce
> >>> the frame size and save energy and bandwidth; in that case you can
> >>> have both properties of deriving the IPv6 address from the MAC and
> >>> replacing a failing device by a virtually identical one.
> >>
> >> I don't mind when this sort of thing is employed for specific
> >> scenarios such as the one you describe. However, it would seem seem
> >> to me that if you really need the addresses to embed the underlying
> >> link-layer address so that you can compress the IPv6 header and keep
> >> the associated overhead at a decent level... one might
> >> (unfortunately) want to reconsider the extent to which IPv6 is really
> >> applicable here, or whether some sort of gateway that bridges a
> >> low-overhead simple protocol with the rest of the network might be a
> better approach.
> >
> > I read that you're wondering if a particular domain should enjoy the benefits
> of IPv6 because of a preconception on how to form IIDs coming from another
> domain. Is that your intent?
> 
> No.
> 
> I'm saying that there's no reason (requirement) for which the IPv6 IID should
> embed the underlying link-layer (for instance, see RFC7136).
> Unlike IPX, IPv6 implements Neighbor Discovery, so the only marginal benefit
> of embedding the link-layer address in the IID is that the resulting address is
> likely to be unique (yet we still have DAD).
> 
> Since the generation of an IID is a host local policy, reliance on the IID being
> any specific value is questionable.
> 
> If such reliance is because the overhead is simply unacceptable, then yes, I
> believe it is a valid question whether IPv6 is the right protocol for whatever
> device/technology needs such compression to keep the overhead track-table.
> 
> YI also agree that there may be valid reasons for which, even if IPv6 was not
> the best fit for your application, but you might still want to use it, and hence
> resort to the hacks such as "header compression".
> 
> The fact that such hack somewhat introduces a requirement that is not present
> anywhere in the ipv6 address architecture (the IID can be anything, since you
> could e.g. manually configure your addresses, they could be dhcpv6-leased,
> etc.), should be a hint in that direction.
> 
> Much of what I've seem to remember seeing in the 6lo et al area seem to be
> tricks to somewhat make IPv6 tractable for the "constrained" scenarios.
> 
> Anyway, believe the IID generation should be the least of your concerns
> here: at the end of the day there's a recommendation (RFC8064) for the
> general case... but you're free to override it. I seem to remember there was a
> proposal by Dave Thaler in this area, meant for constrained nodes, too.
> 
Works for me, Fernando 😊

Pascal