Subject: MUSTs (MUST NOTs) without required protocol failures considered useless

From: Erik Kline <[email-masked]>
Date: Tue, 17 Apr 2018 18:34:02 +0900

As seen on an Android device (via "adb shell dumpsys connectivity")
with an AT&T SIM card with IPv6: a DNS server of fc00:a:a::xxx.
T-Mobile also uses ULAs for DNS, from within "fd00:976a::x" (i.e.,
with L=1).

Both of these seem to violate the MUST to have a randomly generated
Global ID in 4193 section 3.2.1, and the MUST NOT about being
"assigned sequentially or with well-known numbers" in section 3.2.
("a:a" /could theoretically/ have been randomly chosen, but seems
perhaps doubtful)

I strongly suspect that ULAs really are treated by many folks as
"NET-10 for IPv6" and they either don't know or don't care about the
wisdom of the randomness requirements.

At a minimum, it's clear that people can just "try what they did in
IPv4" and if it works they can ship it.

One more reminder that MUSTs/MUST NOTs won't be respected just because
they're in a doc, if there aren't corresponding protocol failures to
catch out folks who, knowingly or unknowingly, violate them.
(Admittedly, it's not easy to think of a hard failure that could be
raised in this scenario, save maybe not having gone down this road in
the first place.)

:-/

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 17 Apr 2018 13:42:22 +0200

Hi Erik,

two points:
a) the IETF is and has no protocol police
   (yes, sometimes we wish we had one :-)

b) protocol failures due to not obeyed MUSTs needs careful
   thought since it will make protcols less robust.
   "Be liberal in what you accept, and conservative in what you send"
   is IMHO also the right guideline in this case.
   In your case, a code that checks for the randomness of the
   40-bit part inside ULAs would make implementations unnecessary
   complex and more fragile. Moreover, users would probably
   not know what the problem is except that IPv6 doesn't work (again).
   So it's better to clearly provide a hint to the network operators
   that they did it wrong and that they should fix it.

Regards
 Roland

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 17 Apr 2018 14:07:05 +0200

>   is IMHO also the right guideline in this case.

  "The Harmful Consequences of the Robustness Principle", Martin Thomson,
  2018-03-04, <draft-thomson-postel-was-wrong-03.txt>

      Jon Postel's famous statement of "Be liberal in what you accept, and
      conservative in what you send" is a principle that has long guided
      the design and implementation of Internet protocols.  The posture
      this statement advocates promotes interoperability, but can produce
      negative effects in the protocol ecosystem in the long term.  Those
      effects can be avoided by maintaining protocols.

(Postel wasn’t wrong, but the robustness principle is often misunderstood and misapplied.)

Grüße, Carsten

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Apr 2018 21:09:53 +0900

>    that they did it wrong and that they should fix it.

No, at this point it's way too late to do anything. The solution would have
been not to put these MUSTs in the spec in the first place. We should have
written the spec, and then predicted that the MUSTs would never actually be
followed. Then we should have removed the MUSTs from the spec to reflect
how the spec would actually have been deployed, and asked ourselves whether
we actually *still wanted* the spec without those MUSTs. I'll bet the
answer would have been "probably not".

The ULA spec goes out of its way not to be the IPv6 equivalent of RFC1918
space. But in the real world, that's exactly how it is used: as an IPv6
equivalent of RFC1918. This was not hard to predict when we wrote the spec,
and we should have known better than to publish it as is. If we wanted to
standardize an IPv6 equivalent of RFC1918 space, then that's what the
document should have said. I'll bet the consensus discussions on that
document would have been very different to the ones we got on the document
that became RFC 4193.

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Tue, 17 Apr 2018 14:16:42 +0200

Hi Carsten,

> (Postel wasn’t wrong, but the robustness principle is often misunderstood and misapplied.)

Thanks for the pointer, but this is a rather general statement.
It would be more interesting to hear whether you think that
the robustness principle is applicable in this particular case.

Cheers,
 Roland

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Apr 2018 08:37:05 +1200

>    (yes, sometimes we wish we had one :-)

Who cares anyway? ULA prefixes should never be routed outside
their home network. That being so, the only real function of the
pseudo-random component is to minimise the chance of collision.
In the sort of deployment mentioned, there seems to be zero chance
of collision anyway. So it doesn't matter. Nothing breaks.

>    complex and more fragile. 

As well as being a mathematical impossibility; fc00:a:a::
and fd00:976a:: are perfectly good random numbers, as is 1234.

    Brian

>    Moreover, users would probably
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 Apr 2018 06:48:01 +1000

> and fd00:976a:: are perfectly good random numbers, as is 1234.

+1

The only thing I'll add is that what we should try to do is ensure that if
people make choices that are contrary to advice, then the consequences of
their choices, as much as possible, are limited to them and them only. In
other words, try to ensure the pain is limited to where it is caused. In
common scenarios, I think ULAs have that property.

Regards,
Mark.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 17 Apr 2018 15:30:16 -0700

Lorenzo,

> On Apr 17, 2018, at 5:09 AM, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Tue, Apr 17, 2018 at 8:42 PM, Bless, Roland (TM) <[email-masked]> wrote:
> 
> No, at this point it's way too late to do anything. The solution would have been not to put these MUSTs in the spec in the first place. We should have written the spec, and then predicted that the MUSTs would never actually be followed. Then we should have removed the MUSTs from the spec to reflect how the spec would actually have been deployed, and asked ourselves whether we actually *still wanted* the spec without those MUSTs. I'll bet the answer would have been "probably not".
> 
> The ULA spec goes out of its way not to be the IPv6 equivalent of RFC1918 space. But in the real world, that's exactly how it is used: as an IPv6 equivalent of RFC1918. This was not hard to predict when we wrote the spec, and we should have known better than to publish it as is. If we wanted to standardize an IPv6 equivalent of RFC1918 space, then that's what the document should have said. I'll bet the consensus discussions on that document would have been very different to the ones we got on the document that became RFC 4193.

Before we had ULAs, we had defined Site-Local addresses that were the IPv6 equivalent of RFC1918 address.  For the reasons stated in RFC 3879 they were deprecated.  ULAs were defined later to provide for a local address without the issues raised by Site-Local addresses.

Bob

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 18 Apr 2018 12:12:57 +0900

> of collision anyway. So it doesn't matter. Nothing breaks.

I think that's exactly the point here. If nobody cares about those MUSTs
being violated, then we shouldn't have put those MUSTs in the document.

What I'm saying is that while we were writing this document, we should have
realized that in the real world those MUSTs would have been generally
ignored, and removed them from the document. We should then have made a
decision about whether the document was a good idea without the MUSTs. The
conclusion may or may not have been different from the conclusion that led
to the publication of RFC 4193 with its current text.

Going forward: if we have reason to believe that a MUST (or even a SHOULD)
is not going to be followed in the real world, then when discussing the
document we should discuss what is going to happen in the real world, not
what is going to happen in an ideal world where everybody ignores
fundamental recommendations of the document, and even, really, its whole
premise.

Think about it: the whole point about ULAs is that they are supposed to be
unique. That property is so fundamental to the design that it's we even
write it in the name of the addresses - the U in ULA stands for unique. But
in the real world, they are not unique. So what's the point of calling them
unique? We should instead have called them "non-unique local addresses" or
just "local addresses". Because that is what they are.

---

From: Roland Bless <[email-masked]>
Date: Wed, 18 Apr 2018 05:32:00 +0200

Hi Brian,

> of collision anyway. So it doesn't matter. Nothing breaks.

You are right, my statement ("wish we had one") wasn't referring to this
particular case :-)

> and fd00:976a:: are perfectly good random numbers, as is 1234.

Yep, sure, so in this case it's even absurd to try such a thing.
My point was also to show that if someone had the idea to implement
something along these lines, something may actually _break_ if the
check code fails (and this is inevitable in this case).

Regards
 Roland

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Apr 2018 16:43:27 +1200

Lorenzo,

The case where ULA prefixes being (very probably) unique matters
is if two networks both using ULAs merge for some operational reason.
That scenario is covered by draft-ietf-anima-autonomic-control-plane,
for example. A related scenario is when a network that assigns its ULA
prefix automatically partitions and for some reason one or both of the
partitions regenerates its ULA prefix, and then the partitions reconnect.

For that reason the MUST, or a very strong SHOULD with narrowly crafted
exceptions, seems to me to be valid.

Regards
   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 18 Apr 2018 08:04:55 +0200

Note:

In draft-ietf-anima-autonomic-control-plane we use a hash to auto-calculate
the ULA prefix, hence we do enforce the property of minimizing collisions
that the MUST was meant to be for (between different ACP networks).

Wrt to the discussion:

I am not sure that the original authors could have had the hindsight that
Lorenzo assumes to have been possible.

I do agree though that if we ever wanted to rev this RFC we could revisit
the MUST and put into better into context. Something like:

> If you want assignments with low probability of collision with another
> ULA network, you MUST use a randomized prefix assignment. See below
> for further details
> 
> ...
> 
> "nasty operator and implementors considerations"
> 
> Note that above MUST
> will not help to avoid collisions with networks that do not care about
> prefix collisions. This document explicitly does not raise the
> MUST requirement against every network though because it could not
> reasonably be enforced. Instead, it is recommended that deployments
> that want the uniqueness do not only use randomn prefix assignments (as
> described here), but also try to guess at the likely non-randomn assignments
> and avoid using those in randomn assignment.

Aka: We shouldn't give up on good ideas just because they may be abused.

If we think we can predict abuse we definitely want to do the best
to mitigate that risk. In the ULA case, we could have used one bit
to indicate randomn or non-randomn ("rfc1918") assignment for example as
proactive separation between those two assignment techniques. Well..
we do still have a bit available, so we could use it for that purpose in a rev.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 18 Apr 2018 19:57:01 +0900

> Lorenzo assumes to have been possible.

Perhaps not. But I don't think that's the main point in this thread. The
main point in this thread is that we should learn from this experience and
keep this example to mind when we write future documents.

> Aka: We shouldn't give up on good ideas just because they may be abused.

It depends on how much the idea is abused. If the majority of usage is
abuse then the original idea is clearly not a good idea.

> proactive separation between those two assignment techniques.

There is already a bit. It's supposed to me the difference between fc00::/8
(randomly assigned) and fd00::/8 (centrally registered, registry TBD). The
examples in this thread show that operators misuse both.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 18 Apr 2018 17:18:45 +0200

> abuse then the original idea is clearly not a good idea.

Or just not good enough. Use of randomness seems to be a particular tricky
proposition for humans. I haven't seen good stats how the randomn assignment
of X.Y.Z in 232.X.Y.Z (SSM multicast) is done, but i would assume that
any human assignments are really not randomn, and only programmatically
done assignments are. How long did it take for port numbers for TCP to
be randomn ? And who cares about our network protocol problem with the
concept when we still haven't come up with a better solution to randomn
passwords for security. Especially when you think that nobody seem to
have been able to figure out the backfire created by forcing humans to
come up with ever more randomn password (your new password must meet
the following 14 rules of constraints...).

[Sorry, you had a good rant, i thought that entitles me to one too ;-) ]

So i would go middle ground. I would certainly think that we coud ask
in review on almost any protocol where randomnness is asked for to discuss
in the text what happens if not and as much as possible think of mitigation
options. Not sure if we could in general go any further. Especially
considering how prety much everything in security is based on the assumption
of a certain degree of security and there are regularily  security hacks
showing how there are some bits fewer security in practiee, and e voila
supposed security problem. 

I think randomness is a frenemy we'll have to live with for a long
time and just need to continuously learn how to better deal with it.

> examples in this thread show that operators misuse both.

Sure. That centrally registered, registry TBD idea was never finished,
so my suggestion was to define that bit, but say its not for a
registry of the prefix, but ALL the space including the prefix is for
local (ab)use, and there is no expectation how to use it, just do not
expect any collision minimization. And then for the existing space,
warn the folks who do use correct randomn assignments (like ANIMA)
that they cold either try to figure out if there are specific
non-randomn assignments to avoid, or to ensure the solution assumes
only leakage between consenting known-randomn assignment networks to
be non-evil.

Thats the kind of ULA rev text i think could make sense. It could also
mention the experiments done with quasi registries in the existing
spaces, and how those closed down, aka: that optimizing non-collision
through additional infrastructure can not be expected to exist
either across randomn, non-collaborating domains.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Apr 2018 09:04:28 +1200

On 18/04/2018 22:57, Lorenzo Colitti wrote:
...
> examples in this thread show that operators misuse both.

Ironically enough, that's the wrong way round. The L bit is set to 1 for
locally assigned ULAs. At the moment, fc00::/8 should never be used.
 
     Brian

---

From: Erik Kline <[email-masked]>
Date: Thu, 19 Apr 2018 17:23:18 +0900

> Before we had ULAs, we had defined Site-Local addresses that were the IPv6 equivalent of RFC1918 address.  For the reasons stated in RFC 3879 they were deprecated.  ULAs were defined later to provi…

My observation from the vantage point of 2016 was that Site-Local
really (probably) wanted to be "provisioning-domain-local" but the
concept of "provisioning domains" didn't get written down until 2015
(7556).  In other words, I think the definition that was missing and
could have worked for "site" is "provisioning domain".  But oh well (I
suppose we could evaluate undeprecating site-local and calling them
pvd-local, but that's probably not a great idea at this point).

But anyway, as Lorenzo observed, the real motivation for my first
email was not specifically ULAs. Rather, as a comment to the folks who
want to do SLAAC on a /73 and think "SHOULD allocate a /64" would
*ever* actually suffice to hold back the race to the bottom.  If
something "just works" when the implementers go to try something, it
may more than likely get shipped that way.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Apr 2018 14:57:23 +1200

Regards
   Brian Carpenter

On 19/04/2018 20:23, Erik Kline wrote:
...
> may more than likely get shipped that way.

Of course. So it's actually irrelevant whether we write MUST or
SHOULD; if the industry collectively decides to change to /73,
it will happen. So far the industry has been happy to coalesce
on an arbitrary /64 for all SLAAC media.

And there is an interoperability reason for that: all nodes
can interwork (for SLAAC purposes) using the factory default.
The penalty for unilaterally setting a different length is
indeed a protocol failure.

    Brian

---

From: Erik Kline <[email-masked]>
Date: Fri, 20 Apr 2018 13:26:22 +0900

On 20 April 2018 at 11:57, Brian E Carpenter
<[email-masked]> wrote:
> ....

Today, yes.

And if >9X% of OSes supported SLAAC on /120s there wouldn't be a
protocol failure about which network providers would necessarily have
to care (your point in the first paragraph).

---

From: Mark Smith <[email-masked]>
Date: Fri, 20 Apr 2018 22:35:36 +0000

On Wed., 18 Apr. 2018, 13:13 Lorenzo Colitti, <[email-masked]> wrote:

> What I'm saying is that while we were writing this document, we should
> have realized that in the real world those MUSTs would have been generally

Following that path results in endorsing the worst decisions and worst
behaviour.

"What you allow, you encourage." - Michael Josephson.

Some people will shoot themselves in the foot regardless of what you do.

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 21 Apr 2018 00:56:38 +0200

> Some people will shoot themselves in the foot regardless of what you do.

How about focussing just on the "considerations" part here. We have focussed
in RFCs so much on "security considerations" where you have an unauthorized
attacker of a system. We have not regularily attempted to ask for 
considerations against an authorized user/operator/implementers of the
system to abuse it and what impact to the design goals this could have

"abuse considerations"

And then there is the question what conclusions to draw from those
considerations.  I think we can not have a single conclusion upfront for 
all type of abuse issues. "If its easy abused, don't build it" certainly
doesn't work well for many cases. Drugs being a typical example, where
abuse happens more than the intended value, yet the right approach to
maximize value from them is not to eradicarte them, but to control them.

In this example too, an abuse consideration might have make some
implementers/operators feel more guily upfront and maybe stopped them ?!
(and or the othrer suggestions from prior emails on this thread)

Cheers
    toerless

---

From: Ca By <[email-masked]>
Date: Fri, 20 Apr 2018 23:54:41 +0000

> maximize value from them is not to eradicarte them, but to control them.

Not sure controlling drugs provides net benefit, so good example.   Drugs
have seen overzealous enforcers take many humane lives ... the road to hell
... good intentions

> (and or the othrer suggestions from prior emails on this thread)

I don’t think the ietf needs nanny-state protocol enforcers.  If you want
to revoke an RFC due to  abuse, i suggest revoking UDP!

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 21 Apr 2018 16:38:36 +0200

On Fri, Apr 20, 2018 at 11:54:41PM +0000, Ca By wrote:
> .... good intentions

The important distinction is whether it can only hurt yourself or
also others. 

In the ULA example using non-random allocations only hurts yourself
in the presence of other "equal-offenders". Good documentation could
be sufficient to deal with that case (warning label).

> I don???t think the ietf needs nanny-state protocol enforcers.  If you want

How do you call TSV CC review for protocols ?  

Cheers
    Toerless

---

From: Fernando Gont <[email-masked]>
Date: Fri, 20 Apr 2018 18:00:50 +0200

> wisdom of the randomness requirements.

Quite likely (and unsurprisingly).

>From the pov of the operator, I wouldn't be surprised if, for an address
that may have to be entered manually multiple times, they want something
with lots of zeroes, that humans can sort of handle (as opposed to 128
bits of randomness).

FWIW, I have been faced with this scenario: selet addresses for the
virtual lab of a couse which, as in the example above, the users had to
type on the console a number of times. 2001:db8::/32 is not usable,
since some router implementation don't route such addresses (some sort
of hardcoded "filter", it would seem). All that you have left is ULAs,
and no, a string of random bits wasn't sensible for this case.

So while I see your point, I also understand hwy these operators may
have decided to go on a different path.

At least when it comes to folks that I've talked to 8that had or were
deploying IPv6), the myriad of changes (at times for doing the same or
similar stuff), is not generally seen as a feature. In retrospective, if
one wanted to specify ULAs as currently specified, then one might have
wanted to also specify private address space a la RFC1918.

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

---

From: Fernando Gont <[email-masked]>
Date: Fri, 20 Apr 2018 18:02:57 +0200

>    that they did it wrong and that they should fix it.

I don't think there was any code checking for randomness of those bits
(in fact, such check is probably impossible). I think Erik was just
pointing out that folks are simply not randomizing the corresponding
bits as required in the ULA RFC.

---

From: Mark Smith <[email-masked]>
Date: Thu, 26 Apr 2018 03:18:14 +0000

> wanted to also specify private address space a la RFC1918.

Did, called site-locals - fec0::/10.

Deprecated because of all the reasons in RFC3879.

TL; DR? Pretty much an invitation for and endorsement of IPv6 NAT. The
random number in ULAs prevents overlapping address spaces when networks
merge.

---

From: Erik Kline <[email-masked]>
Date: Thu, 26 Apr 2018 12:25:08 +0900

> random number in ULAs prevents overlapping address spaces when networks

No argument there.

But note that you're referring to ULAs "when used as directed" (to
quote pharma ads =).

When nearly everyone is using fd::1, fd::2, ... in practice, we will
have gained very little (or indeed nothing).

---

From: Mark Smith <[email-masked]>
Date: Thu, 26 Apr 2018 03:29:02 +0000

> random number in ULAs prevents overlapping address spaces when networks

So the trade off is

(a) spend say no more than 60 seconds coming up with a 41 bit random number
for the ULA prefix (I'm sure there is a smartphone app for that - there
certainly is a website.)

Or

(b) spend $1000s on a IPv6 NAT box in the future + have all the other
ongoing issues that NAT causes when you merge networks with duplicate and
overlapping address spaces.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Apr 2018 15:36:57 +1200

> have gained very little (or indeed nothing).

All we can ever really hope for is to nudge common practice in the
right direction. fd00::1 is probably better practice than 1::1,
just as 192.168.178.1 is better practice than 1.1.1.1.

My CE gives me fd63:45eb:dc14::/48 ; some people do it right.

   Brian

---

From: Erik Kline <[email-masked]>
Date: Thu, 26 Apr 2018 12:37:17 +0900

> for the ULA prefix (I'm sure there is a smartphone app for that - there

This is not a complete assessment of the costs.

It also means keeping track of un-aggregatable /48s (section 3.2,
"Specifically, these prefixes are not designed to aggregate.") and
whatever real or perceived operational cost this may entail.

To be clear: I am not seeking any change in ULAs in particular with
this line of discussion.  I do think we need to be mindful of the real
"behavioral economics" of people interacting the specs as written
though.

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 26 Apr 2018 17:34:08 +0200

> overlapping address spaces.

Well.. Given we do know now that people did not all do (a),
whats your conclusion from that ?

Btw: My conclusion at minimum is that in light of experience it would
be useful to amend ULA to say that you MUST NOT use those 41 bits
combinations that are known to be common non-randomn choices (if your
randomn algorithm unfortunately picked on of those) - if we think there
is such a list.

I am also not persuaded that there is no good reason at all to completely
prohibit the 'rfc1918' type of address allocation. The main reason why
i was happy to see site scoped addresses go away was the expectation
to support multi-zone routing in network devices and the absence of
architectural constraints how to keep that simple (eg: must not
allocate more than one zone per VRF or so). In general i think scoped
address spaces are quite useful, especially when you do NOT intend
to use them with NAT, but instead as a tool for isolation. Alas, even
NAT is useful for address stability as long as we have no better
host transport stacks that would make all application completely
agnostic of dynamic address changes due to mobility or other events.
Maybe we're starting to get those host stacks now, but its been more
than a decade already, so i am not too optimistic.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Thu, 26 Apr 2018 11:14:34 -0500

On 04/25/2018 10:29 PM, Mark Smith wrote:
> 
> On Thu., 26 Apr. 2018, 13:18 Mark Smith, <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
[....]
>     TL; DR? Pretty much an invitation for and endorsement of IPv6 NAT.
>     The random number in ULAs prevents overlapping address spaces when
>     networks merge.
> 
> 
> So the trade off is
> 
> (a) spend say no more than 60 seconds coming up with a 41 bit random
> number for the ULA prefix (I'm sure there is a smartphone app for that -
> there certainly is a website.)
> 
> Or 
> 
> ongoing issues that NAT causes when you merge networks with duplicate
> and overlapping address spaces.

There is more than that. Folks pick predictable addresses for
infrastructure devices because they want addresses that are easy to
remember -- particularly useful in the presence of DNS issues.

Randomness in the prefix also means that the resulting prefixes will
likely not be aggregatable (as noted by Erik).

Last, also keep in mind that the random bits doesn't guarantee there
will not be collisions (if anything for plain bad luck). So at the end
of the day, you still need a fall back plan if you're that unlucky.
Otherwise things will break.

Regarding NATs... I don't seem to find a recent article by G. Huston on
NAT properties. But this one is, not surprisingly, also good:
<https://blog.apnic.net/2017/09/06/opinion-defence-nats/>.

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Fri, 27 Apr 2018 05:35:19 +1000

> <snip>

> have gained very little (or indeed nothing).

Most people try to do the right thing when it is in their interests and
they know it is in their interests.

If people aren't doing ULAs right, it is probably because they don't know
why ULAs have the random component and what benefit it provides.

I expect most people probably believe the only problem being solved by IPv6
is to increase address size. That has really been the only message about it
in the mainstream networking community. Other advantages aren't mentioned
or described.

That means they can adopt an IPv4 with bigger addresses mindset. They
aren't aware of any other problems being solved or other benefits, so they
don't bother trying to deploy those problem solutions or benefits.

I think people not getting ULAs right is a sign that IPv6 has an education
and marketing problem.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Fri, 27 Apr 2018 06:21:55 +1000

> remember -- particularly useful in the presence of DNS issues.

That's a sign that the network is small. Many networks are too large to
remember the sort of device details your describing, and you resort to
things like having an /etc/hosts file and using various neighbour discovery
commands and configurations e.g. OSPF neighbors, ND cache entries, LLDP
neighbors and possibly MDNS if DNS isn't working (and that's not a good
sign either, DNS is critical to your customers, so it should be reliable
too. Rarely should it be unavailable.)

> likely not be aggregatable (as noted by Erik).
I think people are over estimating the need for aggregation to scale
routing today.

The first OSPF RFC (RFC1131) was published in 1989, and that means OSPF and
its methods of routing scaling i.e. areas, were designed in the context of
the RAM and CPU available at that time for a reasonable price. That was 20
to 50 Mhz Intel 386/486 and Motorola 68000s, and a few MB of RAM.

There are still reasons for aggregation within a network, however scaling
routing and routing protocols is much less of a reason given the 100s and
1000s times more amounts of  bandwidth, CPU and RAM available today.

> <https://blog.apnic.net/2017/09/06/opinion-defence-nats/>.

And here he is observing that it is inevitable that the hosts don't and
can't trust the network which includes devices like NATs.

"Hosts vs Networks"
http://www.potaroo.net/ispcol/2016-07/hostsvnets.html

In the great Australian tradition, Geoff is a bit of a stirrer. That means
he'll say something somewhat controversial that also has truth in it, to
get a bit of a rise out of people (you can tell an Australian is doing it
because they've usually got a smile on their face at the time). The other
purpose is to force people to re-evaluate things they might be assuming
without having performed critical analysis of what they think.

APNIC asked somebody else to write an article about the trouble with NAT
just under a year earlier.

"The trouble with NAT"
https://blog.apnic.net/2016/10/25/trouble-nat-part-1/

Regards,
Mark.

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 26 Apr 2018 23:33:26 +0200

> 1000s times more amounts of  bandwidth, CPU and RAM available today.

So.. why then do we have all these new proposals for DC routing ?

Whats in your opinion the best guidance for safe maximum number of routes
in an OSPF area for e.g.: equipment not older than 5 years ?

> http://www.potaroo.net/ispcol/2016-07/hostsvnets.html

Hmm.. not sure i read tt into the article. An application can trust a NAT
as much or as little as any other non-authenticated communications peer.
Security is IMHO a red herring wrt. NAT discussions.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 26 Apr 2018 23:42:26 +0200

Given how i can not find an RFC with IPv6 and "dummy" "beginner" "faq" or
the like in the title i fear you're right. This is probably a complaint
though more for v6ops than for 6man.

Cheers
    Toerless

---

From: Fred Baker <[email-masked]>
Date: Thu, 26 Apr 2018 16:03:07 -0700

> On Apr 26, 2018, at 2:42 PM, Toerless Eckert <[email-masked]> wrote:
> 
> the like in the title

I just grepped the entire RFC database, and didn't find any that contained any of those words. There are 36 internet drafts that do; draft-ietf-anima-grasp refers to something that "uses a dummy ACP module", for example. But no, I don't think you'll find any "IPv6 for dummies" RFCs.

There may be value in your adding a document to the "FYI" series. The most recent, FYI0037, is dated 2000. https://tools.ietf.org/html/rfc2901

---

From: Warren Kumari <[email-masked]>
Date: Thu, 26 Apr 2018 23:26:26 +0000

On Thu, Apr 26, 2018 at 7:03 PM Fred Baker <[email-masked]> wrote:

> I just grepped the entire RFC database, and didn't find any that contained
> any of those words. There are 36 internet drafts that do;
> draft-ietf-anima-grasp refers to something that "uses a dummy ACP module",
> for example. But no, I don't think you'll find any "IPv6 for dummies" RFCs.
>
> There may be value in your adding a document to the "FYI" series. The most
> recent, FYI0037, is dated 2000. https://tools.ietf.org/html/rfc2901

I think, but am not certain, that the IETF stopped publishing the FYI
series.

This does sound like a fine Informational document though...

W

<https://tools.ietf.org/html/rfc2901>
-- 
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: Fred Baker <[email-masked]>
Date: Thu, 26 Apr 2018 18:29:31 -0700

On Apr 26, 2018, at 4:26 PM, Warren Kumari <[email-masked]> wrote:
> I think, but am not certain, that the IETF stopped publishing the FYI series.

Probably because April had moved on. That doesn’t constrain us.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 27 Apr 2018 12:33:59 -0400

> though more for v6ops than for 6man.

I think that we need to leave space in the market for other publishers to
create titles like this :-)

What would be good is if we had a mechanism whereby we did book reviews
(outside of the RFC series. I'm thinking IETF Journal, etc.)
"Books you might want to recommend to your colleagues, or buy for your niece"

Huitema's book is over 20 years old now, I guess.

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