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

From: Nico Schottelius <[email-masked]>
Date: Sun, 05 Apr 2020 22:20:02 +0200

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 5 Apr 2020 20:38:52 +0000

You don’t need to use dhcpv6 to get an address if you don’t want that. Just have client send dhcpv6 Information-Request and it can be provided the boot-url.

- Bernie

> On Apr 5, 2020, at 4:25 PM, Nico Schottelius <[email-masked]> wrote:
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Ole Troan <[email-masked]>
Date: Sun, 5 Apr 2020 22:47:41 +0200

Hi,

I just refreshed a proposal for this exact issue:

https://tools.ietf.org/html/draft-troan-6man-universal-ra-option-02

Is that something you could use?

Cheers 
Ole

> On 5 Apr 2020, at 22:24, Nico Schottelius <[email-masked]> wrote:
> 
>

---

From: Nico Schottelius <[email-masked]>
Date: Sun, 05 Apr 2020 23:12:12 +0200

Salut Ole,

wow, I am very positively surprised, it sounds like a very interesting
idea. I especially like the idea of fast tracking changes and also
direct inclusion of the NAT64 hint in the examples.

However seeing that CBOR is specified, I am not sure whether this is a
suitable representation.  While RAs or DHCPv6 messages are unlikely
something you'll ever see at line rate, I wonder about the effort for
implementing the universal RA in hardware.

You might have a bit more experience with that (mine is rather
limited in the area of P4), can you comment on that? [0]

Besides that, I really appreciate the fresh and easiness of the
approach. I'll discuss with some team mates what they thing about
creating a PoC for it in iPXE.

Best regards,

Nico

[0] I've seen https://github.com/cabo/cn-cbor which has a 1 KiB size
claim, however what I am worried about is the massive variable length
parsing.

---

From: Mark Smith <[email-masked]>
Date: Mon, 6 Apr 2020 07:55:23 +1000

>   "Why don't router advertisements contain a boot url?"

The purpose of Router Advertisements is to configure link specific
layer 3 parameters that are shared by all hosts attached to the link
i.e. MTU, ND parameters, etc.

I think once you start down the path of adding in application layer
parameters into RAs (i.e. applications that run above UDP and TCP,
which includes network booting), you end up going down the path of
reinventing DHCPv6.

For example, you'll want to do host specific parameters, so you'll
need to have host identifiers in RSes and stateful host tracking.
You'll want to have an "RS relay" function in the router so that host
specific parameters can be stored on a central server rather than on
individual routers.

That's a functional description of what DHCPv6 already does.

I think it also violates Internet transparency, where the network is
supposed to be oblivious to applications operating over it. I think
this transparency needs to include being oblivious to configuring
applications too, not just running them:

2.  Internet Transparency and Application Configuration
https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#section-2

Regards,
Mark.

---

From: Nico Schottelius <[email-masked]>
Date: Mon, 06 Apr 2020 12:28:45 +0200

Hey Mark,

thanks a lot for your input.

> i.e. MTU, ND parameters, etc.

That sounds about the right description for a data center network that
is supposed to netboot. Maybe sharing a bit more detail on how a typical
data center is setup for us helps to sheld some light.

Each data center has a base of 3+ networks:

- the internal network: no access from outside, used by pre-boot
  environments and "stupid" hardware that we treat as insecure
  (firmware which cannot be updated, daemons that cannot be firewalled,
  etc.)

- the server network: here all proper configured servers live in. Access
  from outside is possible via SSH only

- the regular networks: for VMs, coworking, etc. with custom firewall
  rules, partially completely open

The pre-boot environment is only active in the internal network. Each
and every system that is loading iPXE in this network is supposed to
load the OS from the network. So the bootfile url is valid for all
systems.

Now comes the interesting part: iPXE has a tiny programming language
alike syntax that allows you to code for specific clients. So while all
clients do netboot, some of them get different information application
based, not network based:

server1..n
  -- loads iPXE from USB
  -- iPXE acquires network information
  -- iPXE gets http://bootserver/ipxe.conf

Based on MAC, BIOS, CPU iPXE chooses a different Linux kernel +
initramfs. Whether the loader is iPXE or something else is out of scope
for this definition and extensions can be vendor specific.

What I want to show with this longer example is that the bootfile URL
can (and should) be the same for all hosts in the same layer 3
network.

And thus I'd still see it fitting as an option to router advertisements.

> which includes network booting), you end up going down the path of

I don't think arbitrary options should be introduced as an RA
extensions, but for this the approach from Ole seems to make sense to
me.

Instead the suggestion is to enable the base functionality of IPv4
dhcp (assign addresses, find dns servers, boot the system) in RAs.

In my opinion, removing the dependency on dhcpv6 "just for netbooting"
could greatly improve IPv6 adaption, because it keeps complexity low.

> specific parameters can be stored on a central server rather than on

As described above, this works directly with iPXE as of today.

> https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#section-2

I tend to disagree with you on this one, as an operating system cannot
be classified as an application in the specific sense. I'd argue that
the proposal does not violate the Internet Transparency, for the
following reason:

The extra field would be just another ICMPv6 option, for which we
already have support. The routers don't behave different depending on
the URL payload and there does not need to be any special treatment. I
would also strongly argue against state based extensions to RAs, because
that is probably one of the most convincing arguments for RAs.

So summarised from my side:

- Host specific extensions don't need and should not be handled in the
  proposed extension
- No state should be introduced into routers
- The proposed extension is valid for all hosts attached to the link

I hope this clarifies the original proposal.
Let me know if you have further questions.

Best regards,

Nico

---

From: [email-masked]
Date: Mon, 6 Apr 2020 13:01:09 +0200

Nico,

> creating a PoC for it in iPXE.

I must admit I did not have hardware implementations in mind with this proposal.
A self describing format, using the RA as an information carrier between "management system" and applications on the hosts. Without having to change code neither in host IP stack/kernel or in router implementations.

For the boot url specifically I would imagine you could get away with a minimalistic CBOR implementation though. Since you just need a URI string.
CC'ed Carsten too, as the ultimate authority on CBOR.

The original proposal was to use JSON directly in the option... I would think that harder to decode... Unless we went back to a more traditional TLV format.

Best regards,
Ole

---

From: Nico Schottelius <[email-masked]>
Date: Mon, 06 Apr 2020 14:18:32 +0200

Salut Ole,

[email-masked] writes:

> [...]
> A self describing format, using the RA as an information carrier
> between "management system" and applications on the hosts. Without
> having to change code neither in host IP stack/kernel or in router
> implementations.

I certainly like the approach. In general, variable length messages or
fields are tricky. What might be easier for the hardware world is to
define a fixed length ICMPv6 option, that does not have to be
parsed. I.e. something on the line of a simple key=value scheme.

For instance if you introduce a new ICMPv6 option that is used with
router advertisements, let's call it "Universal key value option" and
limit it's content to (ASCII or UTF-8) strings, I assume that existing
mechanism could easily be reused.

> CC'ed Carsten too, as the ultimate authority on CBOR.

I'm looking forward to hearing from him. I'm a total CBOR newbie, just
checked the spec on Wikipedia and a couple of github repos so far.

Best regards,

Nico

---

From: Warren Kumari <[email-masked]>
Date: Mon, 6 Apr 2020 08:51:08 -0400

> this is my first post to this mailing list, so please excuse any formal

Hi, and welcome!

> extension of the router advertisements, the "Bootfile URL".

I was wondering how this differs from: draft-qin-6man-nb-option -
https://tools.ietf.org/html/draft-qin-6man-nb-option-03

I wasn't following the progress of this document, and so I have no
idea what the discussions around it were, nor why it was abandoned,
but it certainly sounds very similar - perhaps someone can remember
the discussions?

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: [email-masked]
Date: Mon, 6 Apr 2020 15:03:31 +0200

Hi Warren,

That was one of the drafts that triggered me to propose the Universal RA option.

Best regards,
Ole

> On 6 Apr 2020, at 14:51, Warren Kumari <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Apr 2020 08:46:20 +1200

Ole,

Maybe starting the universal option with a code byte would be wise.
0x00 = TLV, 0x01 = CBOR, etc.

Regards
   Brian Carpenter

On 06-Apr-20 23:01, [email-masked] wrote:
> .

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Apr 2020 18:17:54 -0300

> 0x00 = TLV, 0x01 = CBOR, etc.

+1

This is very important. And prevents being unnecessarily locked in a 
specific way of expressing options.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 6 Apr 2020 22:07:51 +0000

Though then there is the issue as to what happens if device A implements only TLV and another only does CBOR? Do you send both in the RA?

Standardizing on a single method avoids potentially bloating RAs or having to send multiples for the different formats.

BTW: I don't think the boot-url is a good one to include in RAs. While the use case described might be able to use it, an arbitrary network with many different device times could not as the information would likely depend on the device.

- Bernie

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Fernando Gont
Sent: Monday, April 6, 2020 5:18 PM
To: Brian E Carpenter <[email-masked]>; [email-masked]; Nico Schottelius <[email-masked]>
Cc: [email-masked]; jason.kim <[email-masked]>
Subject: Re: [proposal] adding boot-url to router advertisements

+1

This is very important. And prevents being unnecessarily locked in a specific way of expressing options.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Apr 2020 10:21:51 +1200

> Though then there is the issue as to what happens if device A implements only TLV and another only does CBOR? Do you send both in the RA?

Indeed, that's always the downside of flexibility. But while I'm a strong CBOR fan, and have some evidence that it is no slower to decode than TLV in software (or firmware), I do think the question is open for FPGA or custom silicon decoders.

   Brian

---

From: [email-masked]
Date: Tue, 7 Apr 2020 10:43:32 +0200

Hi Brian,

> 0x00 = TLV, 0x01 = CBOR, etc.

The idea behind the universal option experiment was "if we take a self describing data format, could we then relax the need for IETF review and specification"?

TLVs with custom parsing of the Vs aren't quite compatible with that I think.

If you need TLVs you can get a 'normal' ND / DHCP option. Or we could even make another container option for TLVs if need arose?

Best regards,
Ole

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Apr 2020 06:55:34 -0400

> way of expressing options.

I think that we can well afford two RA option values, if we really want this.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Apr 2020 13:18:39 -0300

> The idea behind the universal option experiment was "if we take a self describing data format, could we then relax the need for IETF review and specification"?

What I wonder here is whether the stopgap for things like e.g. a DHCPv6 
route option is the IETF, are having implementations of those.

If the former, what you propose would certainly help (and shame on us, 
too!), if the later then you'd still have universal options that are are 
not implemented by major vendors (and we'd be where we are now).

Of course, one might give the experiment a try anyway, and see how 
things evolve.

> TLVs with custom parsing of the Vs aren't quite compatible with that I think.

Is there really much of a difference with custom parsing vs. universal 
parsing (but not knowing to do with what you parsed)?

---

From: [email-masked]
Date: Tue, 7 Apr 2020 19:39:40 +0200

Fernando,

> What I wonder here is whether the stopgap for things like e.g. a DHCPv6 route option is the IETF, are having implementations of those.
> 
> If the former, what you propose would certainly help (and shame on us, too!), if the later then you'd still have universal options that are are not implemented by major vendors (and we'd be where we are now).
> 
> Of course, one might give the experiment a try anyway, and see how things evolve.
> 
> 
> 
> Is there really much of a difference with custom parsing vs. universal parsing (but not knowing to do with what you parsed)?

There is some difference. E.g. well tested.
The self describing data format supports lists, hashes etc.

The biggest "hoped for" difference, is the separation of the carriers of the data and the users of the data.
That is you don't need changes to a host kernel implementation or a router OS.

An application subscribes to a given "key" and gets that object if it appears in an RA.
In that sense you don't care about what no-one is subscribing to.

Cheers,
Ole

---

From: Nico Schottelius <[email-masked]>
Date: Tue, 07 Apr 2020 20:59:53 +0200

> I think that we can well afford two RA option values, if we really want this.

That might be a smarter option. However, at the moment I don't see yet
how CBOR would be supported in silicon at all, which would lead to only
one option being implemented in hardware.

---

From: Nico Schottelius <[email-masked]>
Date: Tue, 07 Apr 2020 21:10:57 +0200

Good evening,

> https://tools.ietf.org/html/draft-qin-6man-nb-option-03

wow, I haven't seen this! I'm following up with the authors right now to
find out what the status was/is.

> but it certainly sounds very similar - perhaps someone can remember

A quick look into it shows that it is probably about 85% overlapping
with our proposal, with the difference of the reserved fields and the
padding proposal.

I personally would also *not* advocate to support individual nodes
configuration, to keep the routers stateless, which is in my opinion
still one of the biggest advantages of RA vs. DHCPv(4,6).

Best regards,

Nico

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 Apr 2020 10:29:14 +1200

> If you need TLVs you can get a 'normal' ND / DHCP option. Or we could even make another container option for TLVs if need arose?

I understand the arguments against including a code byte. But on the other hand, if you had both a CBOR and TLV option there would be pressure to support both always...

One other point is that if an option is defined as a classical TLV and its value is the byte string 0xdeadbeefcafe,  then its CBOR encoding is 0x46deadbeefcafe (where "6" is the length). That oversimplifies a bit, but hardware decoding of the CBOR representation of a bytestring is plausible.

     Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Apr 2020 19:43:34 -0400

> one option being implemented in hardware.

While I understand why some options need to be in hardware, I'm not sure that
I understand why the all have to be.
For quite a number, being sent, rate controlled, the control plane would seem to be enough.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 8 Apr 2020 17:52:49 +0100

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.

>>    "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

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 Apr 2020 06:47:38 +1000

The "damn thing" already works, some people just don't like how it works.
You're not presenting a good faith argument by saying it doesn't.

The only actual argument is "it's different to what I'm used to, so I want
another solution that works the way I want it to."

That would create a duplication cost in all areas of design, development,
implementation, training and troubleshooting. With how many IPv6 nodes
there are now, those costs are easily going to be in the many millions if
not 100s of millions of dollars, euros etc., all just for somebody's
personal preference.

Personal preference doesn't justify duplicating functionality of an
existing solution that works, in particular when it will then introduce
confusion as to which solution to implement and deploy.

People risk mitigate by not making a choice when they think they might make
a wrong choice. Having multiple solutions to a problem where there is no
significant difference between them, meaning it is clear when to deploy one
or the other, will slow down IPv6 adoption, not speed it up.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 8 Apr 2020 21:57:50 +0100

Mark Smith wrote on 08/04/2020 21:47:
> The "damn thing" already works, some people just don't like how it 
> works. You're not presenting a good faith argument by saying it doesn't.

Hi Mark,

I was very clear about both of these points in my email:

> unnecessary, if not somewhat artificial

and

> The position of most ND/RA proponents
> protocol interaction architecture.

Nick

---

From: Mark Smith <[email-masked]>
Date: Thu, 9 Apr 2020 07:09:36 +1000

> I was very clear about both of these points in my email:

"The ietf ipv6 working group is
less concerned about how to make the damned thing work: "

Aren't you saying here that you don't think it works and that you think
6man are both ignoring that and don't care that it apparently doesn't work?

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 9 Apr 2020 00:25:05 +0100

Mark Smith wrote on 08/04/2020 22:09:
> >"The ietf ipv6 working group is less concerned about how to make the damned thing work: "
> 

No, I was talking about "how to make the damned thing work" in the 
general sense of how to make a network run, and ideally run smoothly. 
It wasn't intended as a either a reference to dhcpv6/slaac or even to 
Nico's issue.

The purpose of the 6man working group was described roughly as:

> it's more about

You get an architect to design a house and builder to build it, and the 
owner to turn the resulting pile of bricks, metal and wood into a home.

The IETF is the architect, the kit vendor is the builder, and "how to 
make the damned thing work" was intended to refer to the home-owner who 
turns the output of the architect and their builder into their own comfy 
pad.  Often their job involves working around bumps and annoyances 
caused by the other two.

Nick

---

From: tom petch <[email-masked]>
Date: Thu, 9 Apr 2020 08:31:40 +0000

Nick

Brilliant!

This reminds me, as a consultant used to say to me, there are management solutions to technical problems but not technical solutions to management problems from which you will infer that I see this as a management problem.  I also see the IETF as an organisation without management, in a sense, and so with no way forward.  The only smidgeon of hope is that in the past the IETF has come up with two solutions and gone forward with both and let the market place sort it out but I believe that was when the IETF was smaller, more close-knit, more inclined to go forward thus; or perhaps the market place was less influential.  Whatever, looking forward (!) to the next 25 years, the next generation of engineers seeking to untie this Gordian knot,

Tom Petch
From: ipv6 <[email-masked]> on behalf of Nick Hilliard <[email-masked]>
Sent: 08 April 2020 17:52

Nico,

Some things are clear:

Nick

---

From: Sander Steffann <[email-masked]>
Date: Tue, 7 Apr 2020 22:14:27 +0200

> still one of the biggest advantages of RA vs. DHCPv(4,6).

Don't forget that there is Stateless DHCPv6! ;)
Sander

---

From: Erik Kline <[email-masked]>
Date: Sun, 12 Apr 2020 23:08:04 -0700

> still one of the biggest advantages of RA vs. DHCPv(4,6).

Another option is to include a PVD option, and try to add a boot-url key to
the PVD info in the PVD server reply.