Subject: Re: [proposal] adding boot-url to router advertisements

From: Nico Schottelius <[email-masked]>
Date: Tue, 21 Jul 2020 10:50:14 +0200

Hey Nick and everyone,

sorry for the late reply, I had to dig a bit more into the background
and do some reading.

In practical terms, we have two services that kind of compete, because
of their overlap of use cases.

I honestly don't want to, nor can I take position to say "one is better
than the other". However, I also don't believe this to be a
problem. Both services can and probably will evolve in the next years
and one or the other will fit for a particular use case.

IPv6 at the moment is growing in a lot of areas, so we will see changes
or change requests because of wider use. I think we are now at a stage
of natural evolution of IPv6, going a bit further away from the drawing
board approach, entering a "practical requirements stage".

I understand that adding new features to any standard triggers a length
process at the vendor side.

So my proposal is as follows: our team at ungleich will patch 2 widely
used open source software packages (radvd [0] and ipxe [1]) to provide a
sample implementation of boot-url support as a better discussion basis.

I hope this way it is easy to see what possible modifications will be
there for a standard change.

I'll follow up with a demo & pointer to the source code as soon as we
have something to show.

Best regards,

Nico

[0] https://github.com/reubenhwk/radvd
[1] https://ipxe.org/

Nick Hilliard <[email-masked]> writes:

> Nico,
>
> there's a history of difficulty relating to the interaction of dhcpv6
> and the RA component of IPv6 neighbour discovery.  This history goes
> right back to the first dhcpv6 specification draft in 1995.
>
> The original architecture was that ND/RA should handle "kernel" level
> connectivity parameters, for example the subnet prefix, default
> router, MTU and netmask, i.e. enabling ipv6 address self-selection,
> which would be enough to get a host up and running.  If the address
> auto-selection model was insufficiently flexible for the operator,
> DHCPv6 could be used instead to handle application-level things like
> DNS configuration and all of the normal rich feature set that DHCP
> generally provides.
>
> The problem was: this didn't work in practice.  Regular operators and
> users assumed that ND/RA on its own would be sufficient to allow
> auto-configuration of devices to the point that it would "work", but
> of course nothing really works without DNS support, which is a host
> level parameter, i.e. DNS was very clearly outside the architectural
> scope for ND/RA.
>
> Conversely many operators looked at the relationship between ND/RA and
> DHCPv6 and felt that the interdependence of one on the other was
> unnecessary, if not somewhat artificial. In particular if DHCPv6 had
> the prefix information and default route options, that this dependence
> would disappear and there would no longer be a requirement to use
> ND/RA at all.
>
> Because of differences in expectations, the IETF has ended up with a
> 25 year stand-off between proponents of one side and the other, which
> at this stage is thoroughly wedged.  The position of most ND/RA
> proponents is that there is nothing fundamentally broken, and that
> operational positions concerning adding prefix assignment and
> default-route to dhcpv6 are simply misplaced because they're
> inappropriate for the protocol interaction architecture.  On the
> DHCPv6 side, many people would like to see prefix assignment and
> default route options in the protocol, which would give them the
> ability to run dhcpv6 without ND/RA, and then everyone could get on
> with their lives and start arguing about more important stuff.
>
> From a practical point of view, this has meant that any time anyone
> has suggested adding a new features to one protocol where there was
> the possibility that it should be added to the other, an eruption
> would ensue, typically involving a mailing list thread running into
> hundreds of posts.  Over the years, these arguments have consumed an
> extraordinary amount of time across the dhc, mif, 6man and v6ops
> working groups, along with [email-masked].  Despite the hot air, no
> consensus emerged which could resolve each sides' differences.
>
> The result of these arguments was that any attempt to get the prefix
> information and default route options into DHCPv6 failed, and most
> attempts to get host-level options into ND/RA failed, with some fairly
> high profile exceptions like RDNSS and more recently pref64.
>
> All that said, you have legitimate operational issues, which is to say
> that you want your equipment to work.
>
> I'm going to go out on a limb on this one, and suggest that you may
> not be in the right place for this question.  The ietf ipv6 working
> group is less concerned about how to make the damned thing work: it's
> more about maintaining the ipv6 protocol, and some of mandate this
> relates to how to define protocols which will hopefully withstand the
> test of time.
>
> There is a subtle but important difference between making things work
> and defining new protocols / maintaining existing ones.  But
> nevertheless, it's probably worth a shot.
>
> Regarding the questions you asked:
>
>>>    "Why don't router advertisements contain a boot url?"
>>> [...]
>>>    "Why should we not be able to netboot, without dhcpv6?"
>
> These are reasonable questions to ask.  You've identified that there
> is questionable overhead here, and that this overhead is unwelcome for
> your use case.
>
> I'm going to go out on another limb and suggest that what you're
> really asking here is why we don't have a single, relatively simple,
> unified auto-configuration protocol which is extensible enough for
> general-purpose-to-advanced use.  In your case, those purposes would
> include net-booting, but there would be no reason to exclude other
> purposes.
>
> It's not clear how much you care about the protocol that's used.  Both
> ND/RA and dhcpv6 use TLVs so in some senses, it doesn't matter that
> much from your point of view.
>
> Another way of looking at your question would be: if there were a
> single, relatively simple, unified auto-configuration protocol which
> could handle host provisioning to the point that it dealt with your
> requirements - regardless of whether it was ND/RA, DHCPv6 or something
> else entirely - would you be bringing your concerns to 6man@ietf?  I
> suspect probably not.
>
> In other words, your issue seems to hinge on the fact that there are
> two protocols for configuring hosts in IPv6, that neither of them has
> enough options defined for your use case, and that having two
> protocols causes you enough unhappiness that you feel it's worth
> addressing the problem. From an operational point of view, that's a
> pretty high level of unhappiness.
>
> A boot URL option is firmly a host-level issue, so in the general ipv6
> architectural scheme, the option rightly belongs in DHCPv6.  However
> this doesn't solve your problem because you want to dispense with
> operational complexity because DHCPv6 is dependent on ND/RA for prefix
> assignment and default route.
>
> ND/RA is marginally simpler, so why not there?  Well because it's a
> host level parameter so it doesn't belong there from an architectural
> point of view.
>
> So why not make an exception for ND/RA for this use case?  Indeed, why
> not.  Alternatively, why not standardise prefix assignment and default
> route options in dhcpv6, then ditch nd/ra and use standalone dhcpv6
> instead, optionally in a cut-down form which would reduce your
> specific overheads?  Either option would resolve your use case.
>
> But if you argue it one way, then one set of people will block
> progress; if you argue the other way, it will be a different set of
> people.  Of course, everyone has had well-rehearsed reasons for
> holding their opinions, but at the end of the day operators of
> production services often just need things to work, and these endless
> debates do nothing to promote this cause.
>
> Sadly this impasse has continued since the mid 1990s.
>
> Some things are clear:
>
> 1. there are good operational reasons to want a single,
> clearly-defined autoconfiguration protocol, and
>
> 2. the name and the exact encapsulation format doesn't matter in the
> greater scheme of things.
>
> 3. for any position put forward, there will be disagreement.
>
> Whether a single unified protocol involved a wholesale import of DHCP
> parameters into ND/RA, or adding a prefix information option and
> default route option to DHCPv6, in each case with semantic guidelines
> about how to handle protocol overlap, it wouldn't matter much in the
> greater scheme of things.
>
> Could one protocol be encapsulated in the other?  Of course it could,
> but why would you do this when there are other technically simpler
> options to handle the use-case requirements.
>
> It's not clear that Ole's draft is going to solve anything in the
> longer term.  It seems unlikely that vendors are going to implement a
> new protocol with a 2y life-span.  Would TLVs be a better choice than
> CBOR? Does it show that people who are unhappy about adding options to
> ND/RA are less likely to object if the options are made a little bit
> more unpalatable by adding in an extra layer of encapsulation?  And if
> so, does that tell us anything about their motivation?
>
> All that said, a fresh set of eyes on this problem would be
> welcome. Perhaps there is something this working group missed from an
> operational point of view?  Maybe you could explain more about what
> your constraints are and what would work for you?  As a production
> services operator, your opinions would be very welcome - there are not
> many of us operators here!
>
> Nick
>
>
> Nico Schottelius wrote on 05/04/2020 21:20:
>>
>> Good morning ladies and gentlemen,
>>
>> this is my first post to this mailing list, so please excuse any formal
>> errors.
>>
>> I'm working for the Swiss hosting provider ungleich [0], which provides
>> IPv6 only [1] and IPv6 first services.
>>
>> There is one peculiar question that frequently comes up in our
>> infrastructure team and I would like to take this question as a start
>> for a proposal. That said question is:
>>
>>    "Why don't router advertisements contain a boot url?"
>>
>> We are aware that there is dhcpv6, that it does contain code 59,
>> frequently mapped as "dhcp6.bootfile-url". So the question here is not,
>> "how can I IPv6 netboot", no. The question much more is
>>
>>    "Why should we not be able to netboot, without dhcpv6?"
>>
>> Which leads me to a quick fact check on RAs, which currently support:
>>
>>   - DNS servers
>>   - DNS search path
>>
>> The ICMPv6 option field seems extensible enough to support one more
>> option. For this reason I'd like to propose and discuss the following
>> extension of the router advertisements, the "Bootfile URL".
>>
>>
>> Bootfile URL
>> ------------
>>
>> We propose to introduce a new ICMPv6 option with type XX (TBD), length
>> URL dependent in a similar fashion to the DNS Search List Option
>> (compare [2]).
>>
>> The URL should be formatted as described in RFC3986. The bootfile URL is
>> an optional ICMPv6 field.
>>
>> If present during a network boot process, the host firmware should load
>> the specific firmware as its operating system.
>>
>> If the managed flag is set in the router advertisement and code 59 is
>> set in the DHCPv6 response, the DHCPv6 response should be preferred over
>> the router announcement bootfile URL, if present.
>>
>> Rationale
>> ---------
>> IPv4 to IPv6 transitions are becoming a regular work. While DHCPv6 has a
>> superior set of options compared to router advertisements, rarely all of
>> them are necessary.
>>
>> To simplify transition from IPv4 to IPv6, we advocate of removing the
>> dependency on a second service (DHCPv6), to ease transition and
>> maintenance of IPv6 networks.
>>
>> If both protocols are present and indicating a bootfile url,
>> we suggest to prefer the DHCPv6 URL, as it is more likely to have state
>> dependent configurations in DHCPv6 than in router advertisements (the
>> latter would require specific filtering, as router advertisements are
>> usually multicasted to all nodes).
>>
>> Data Centers and network boot environments more often depend on the Open
>> Source bootloader iPXE [3]. Given this dependency,
>> adding support for booting from the router advertisement bootfile-url
>> could be easily added to newer equipment and possibly even added with a
>> firmware update to existing firmware.
>>
>> --------------------------------------------------------------------------------
>>
>> I hope this message is addressed to the right people and I am looking
>> forward to your input.
>>
>> Best regards from Switzerland,
>>
>> Nico
>>
>>
>> [0] https://ungleich.ch
>> [1] https://ipv6onlyhosting.com
>> [2] RFC 8106
>> [3] https://ipxe.org/
>>
>> --
>> Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>

--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 21 Jul 2020 12:51:55 +0100

> I'll follow up with a demo & pointer to the source code as soon as we

Running code sounds good.  There are practical guidelines set out in 
rfc4727 and there's a list of existing code points on the IANA site:

> https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5

+ some experimental values if you're testing out code (253, 254).

Nick

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Tue, 21 Jul 2020 20:50:45 +0000

On 21 Jul 2020, at 8:50, Nico Schottelius wrote:

Hi,

> sample implementation of boot-url support as a better discussion 

sorry for my ignorance in this thread or whether this was discussed 
before.

How would an EFI implementation currently retrieve this value at this 
point for IPv6?

/bz

---

From: Nico Schottelius <[email-masked]>
Date: Tue, 21 Jul 2020 23:03:55 +0200

Good evening Bjoern,

> How would an EFI implementation currently retrieve this value at this

it would read the information from the router advertisement - the same
way an EFI implementation is acquiring itself an IPv6 address or DNS
server information at the moment.

HTH.

Cheers,

Nico

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Tue, 21 Jul 2020 21:06:41 +0000

> server information at the moment.

No, I mean how does an EFI implementation CURRENTLY ALREADY do this.

EFI does support IPv6 netboot in the specs to my best knowledge; and 
they can boot from e.g. http.
So somehow this problem must have been solved already (at least in 
theory), maybe just not here.

/bz

---

From: Mark Smith <[email-masked]>
Date: Wed, 22 Jul 2020 07:59:27 +1000

> board approach, entering a "practical requirements stage".

A solution to this problem already exists.

https://tools.ietf.org/html/rfc5970

You need to write an Internet Draft to discuss and describe your proposal,
which needs to include justifying why having two fairly similar solutions
to the same problem should exist.

Two similar solutions to the same problem just cause confusion, incurs
duplicate development costs, and delays deployment, as eventuated with DNS
options in both RAs and DHCPv6.

https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft/

More choice isn't always good.

---

From: Nico Schottelius <[email-masked]>
Date: Wed, 22 Jul 2020 16:30:57 +0200

Hey Bjoern,

> theory), maybe just not here.

currently EFI firmware has to use DHCPv6 for this and you need to run an
additional dhcpv6 server next to the stateless router advertisements.