Subject: Re: [v6ops] Turning on IPv6 Routers (was PPPoE requirements)

From: Tim Chown <[email-masked]>
Date: Wed, 2 Aug 2017 13:46:10 +0000

Hi,

> On 26 Jul 2017, at 22:44, Mark Smith <[email-masked]> wrote:
> 
> <snip>
> 
> No. On PPP you don't need DAD for LLA.
> 
> I think you now do per RFC8064/RFC7217.
> 
> I don't really understand the motivation for avoiding DAD. It's a very marginal saving (1 packet) in comparison to the problems and time involved in troubleshooting duplicate addresses.
> 
> In the scenario described, it can be much worse because there is likely a non-technical end-user and a helpdesk involved in what can be an intermittent and obscure fault (Helpdesks can be motivated to get the customer off the phone by saying "reboot the modem and call us back if you have more problems", which doesn't prevent the fault re-occurring.)
> 
> I think absolute and consistent failure is much better and easier to troubleshoot than partial and intermittent failure when the cause is simple to determine and discover.

To step up back to the original question, what specific text or guidance should be in draft-ietf-v6ops-ipv6rtr-reqs-00, or even RFC6434-bis (hence my interest), with respect to IPv6 CPEs shipping with IPv6 enabled by default?

This is what the draft currently says about provisioning: https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs-00#section-3.3

Is that sufficient? 

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Aug 2017 09:01:14 +1200

> This is what the draft currently says about provisioning: https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs-00#section-3.3

This seems under-specified to me:
"SLAAC MUST be able to be disabled by operators
who prefer to use some other mechanism for address management and
assignment (specifically for customer facing edge ports)."

Shouldn't that be more precise? Running SLAAC is actually mandatory, as far as
configuring LL addresses goes. So it can't be "disabled" as such. I think this
wants to say that it MUST be possible to configure RA/PIOs with A=0.

In turn that means that RFC4861 MUST be supported - and that isn't even
cited anywhere in the draft. Doh! An IPv6 router without RAs would be a
strange beast.

    Brian

---

From: [email-masked]
Date: Thu, 03 Aug 2017 05:56:31 +0200 (CEST)

> wants to say that it MUST be possible to configure RA/PIOs with A=0.

Or configure no RAs at all. LL address generation is *not* dependent
on RA (but *does* depend on NS/NA/DAD).

It is perfectly possible to run IPv6 routing without RA (even if you
don't normally want to do that). Check your nearest Juniper router
if you doubt this is possible.

Steinar Haug, AS2116

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Aug 2017 17:34:32 +1200

> if you doubt this is possible.

Where does the default router address come from, then? 

   Brian

---

From: Mark Smith <[email-masked]>
Date: Thu, 3 Aug 2017 15:41:24 +1000

> Where does the default router address come from, then?

And potentially many other things:

"IPv6 RAs Mostly Necessary"
https://www.slideshare.net/MarkSmith214/ipv6-ras-mostly-necessary

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

---

From: Gert Doering <[email-masked]>
Date: Thu, 3 Aug 2017 09:30:49 +0200

Hi,

> Where does the default router address come from, then? 

On the router?  "OSPF, BGP, ..."

On the host?  "static route pointing to fe80::1%eth0"  (which is the VRRP
address of your upstream router pair)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Mark Smith <[email-masked]>
Date: Thu, 3 Aug 2017 18:02:32 +1000

> address of your upstream router pair)

I suppose there should also be a knob to turn neighbor resolution off
too, so that people can exclusively use statically configured ND cache
entries in routers.

Regards,
Mark.

---

From: Gert Doering <[email-masked]>
Date: Thu, 3 Aug 2017 10:11:57 +0200

Hi,

> too, so that people can exclusively use statically configured ND cache

That's a different bag of worms, but indeed, a knob to replace NS/NA with
something reasonable would be good.  "Static ND cache" is not an exactly
common request, though - but in a fully pre-defined scenario (think 
industrial ethernet which already does away with MAC learning), this
has benefits.

Seriously: RAs for default router announcement work nicely for certain
use cases, and are just not good enough for others, like "fast and 
well-defined failover among multiple default gateways".

But do not let me stop you from ridiculing other people's use cases - this
is part of what has made IPv6 such a tremendous success, so by all means,
give us more of it.

Gert Doering
        -- NetMaster

---

From: Mark Smith <[email-masked]>
Date: Thu, 3 Aug 2017 19:32:07 +1000

> industrial ethernet which already does away with MAC learning), this

It would be an alternative method of mitigating ND cache attacks,
which are exploiting dynamic ND cache entry creation.

> well-defined failover among multiple default gateways".

That's what VRRP, HSRP or GLBP are for. VRRP supporting IPv6 was
specified in 2010 in RFC5798, and a search shows that Cisco have
supported IPv6 in HSRP and GLBP since 2011.

RAs plus NUD is going to be a poor mans or better than nothing VRRP.
There was no such equivalent functionality in base IPv4. The out of
the box IPv6 functionality is not better than VRRP/HSPR/GLBP, however
it is better than IPv4's.

> But do not let me stop you from ridiculing other people's use cases

I usually understand the use cases, however I don't understand why the
methods used in IPv6 must be the IPv4 methods, even though IPv6
methods exist and are deployed and are working for many people.

People usually don't actually describe why the existing and widely
deployed IPv6 methods cannot be used. They just assert it must be the
way IPv4 worked. It's understandable because of familiarity, however
things can't be improved without things being changed.

Sometimes they also assert what they're objecting to is "religion".
Asserting it is "religion" is implying that there was no objective or
rational reasoning behind the decision (there always is), which is
really just resorting to an ad hominem attack on the person they
disagree with and also those who made those design and protocol
decisions.

Things should always be objectively evaluated here. I think blindly
carrying over IPv4's practices and methods to IPv6 is closer to
religion than anything that appears in IPv6 - it is saying "even
though the situation and requirements have changed, we believe the old
ways are and will always be the best ways". I think that is a very
subjective approach.

> - this

The best way to prove the IPv6 methods don't work is to deploy the
IPv6 methods as they stand. If they fail, document the environment
they failed in and how. Come back with that evidence, which may
provide a solid reason to change how IPv6 works in that specific
regard.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Aug 2017 08:23:28 +1200

> too, so that people can exclusively use statically configured ND cache

Once you say "static" and "configured" you're outside the scope of
default behaviour and automatic configuration. If that's in scope
for the draft, fine, but it needs to be described much more explicitly
than a throw-away line like "SLAAC MUST be able to be disabled by operators
who prefer to use some other mechanism..." which is what I was commenting
on.

Remember that the section of the draft including that text is titled
"Supporting Zero Touch Provisioning for Connected Devices". And
(for example) VRRP isn't mentioned anywhere in the draft.
(https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs in case
anybody has lost track.)

    Brian

---

From: Gert Doering <[email-masked]>
Date: Thu, 3 Aug 2017 22:50:50 +0200

Hi,

> >> > address of your upstream router pair)
[..]
> it is better than IPv4's.

Which is exactly what I've been saying as a possible reason why people
are running without default-route-from-RA.  

So it seems I am misunderstanding your point.

[..]
> methods exist and are deployed and are working for many people.

We do use the IPv6 method:  HSRP with an IPv6 LLA (because that *is*
"the IPv6 method", as on all but one platform Cisco's HSRP for IPv6
does not permit configuring a GUA as HSRP address, which would be
"the IPv4 way").

We've done RA based failover, and it was far too slow and far too 
non-deterministic ("honour router priorities?  why?") to be satisfying.

[..]
> provide a solid reason to change how IPv6 works in that specific

While I agree with you, this is just so slightly straying off the original
question I've replied to...

And yes, I've tried most of "the IPv6 ways" to get things done, and my
dislike is growing.  Like, how comes there is no remote ARP attack on 
anything, but multiple router platforms are vulnerable to remote ND
attacks...  (not speaking of neighbor cache exhaustion, but of the
incoming queue saturation by bogus packets coming from anywhere bug).

Using ICMP with (among others) GUAs for IPv6 ND was a tremendously bad
idea.  First you open an attack surface for off-link attacks, and then
you hope that implementations would be able to do hopcount=255 filtering 
early enough that you do not drown out legitimate packets in a rate-
limited queue later on...

Gert Doering
        -- NetMaster