Re: Curious Cloudflare DNS behavior

[John Sage]

On 5/30/20 11:58 AM, Saku Ytti wrote:

[This post may portray opinions as facts, click to see the post]

On Sat, 30 May 2020 at 21:55, Constantine A. Murenin  wrote:


When you're not paying for service, you're not the customer, you're the product.

I don't understand why anyone, especially anyone frequenting NANOG, would use 
Cloudflare for their DNS.

[promised myself I wouldn't get pulled off into any smoldering flamewars]

[oh well. fools rush in   ]

Actually I used to run a caching-only nameserver using bind, as well as 
my own email server using sendmail, behind an ipchains/iptables firewall 
on a Linux box that was also running snort.


This would have been about (counts fingers; toes) maybe 1998-99.

So I have done this for myself, thank-you-very-much.

Times are a little more complicated now and I've come to want my own 
personal life to be a little simpler, again, thank-you-very-much.


Then (or finally) not to be pedantic, but I did open with:

>> FULL DISCLOSURE: this is an end-user issue, but one that might have
>>some operational relevance, particularly if anyone from Cloudflare DNS
>>is on the list

"End-user"

No one should say they weren't warned.

#EOF


- John
--
John Sage
FinchHaven Digital Photography
Box 2541, Vashon, WA 98070
Email: js...@finchhaven.com
Web: https://finchhaven.smugmug.com/
Old web: http://www.finchhaven.com/
Cell: 206.595.3604

Re: Contact at Ubiquiti Networks?

[Nuno Vieira via NANOG]

Ubiquity is definitely a NO GO.

They RMA/Support is either NON EXISTENT or Anedotic.

Got broken/failed equipment in the Spanish distributor for more than 10 months 
waiting for repair or replacement, they simply say its Ubiquity to blame...   

Anyways, i don't care and just requested a full refund on the products...  If i 
was waiting for a replacement i would be dead already :)  

And all this is a shame, i started to use Ubnt a long ago... around 2008...

Nuno Vieira


- Original Message -
> From: "Mike Hammett" 
> To: "j k" 
> Cc: "North American Network Operators' Group" 
> Sent: Monday, 25 May, 2020 21:21:00
> Subject: Re: Contact at Ubiquiti Networks?

> The company has mostly fallen apart. Their sales are going up, but their
> responsiveness and customer support have been declining over the last five
> years.

> -
> Mike Hammett
> [ http://www.ics-il.com/ | Intelligent Computing Solutions ]
> [ https://www.facebook.com/ICSIL ] [
> https://plus.google.com/+IntelligentComputingSolutionsDeKalb ] [
> https://www.linkedin.com/company/intelligent-computing-solutions ] [
> https://twitter.com/ICSIL ]
> [ http://www.midwest-ix.com/ | Midwest Internet Exchange ]
> [ https://www.facebook.com/mdwestix ] [
> https://www.linkedin.com/company/midwest-internet-exchange ] [
> https://twitter.com/mdwestix ]
> [ http://www.thebrotherswisp.com/ | The Brothers WISP ]
> [ https://www.facebook.com/thebrotherswisp ] [
> https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg ]

> From: "j k" 
> To: "NANOG list" 
> Sent: Monday, May 25, 2020 3:16:36 PM
> Subject: Contact at Ubiquiti Networks?

> Does anyone have a good contact at Ubiquity Networks? Finding a pattern I 
> don't
> like.

> Joe Klein

> "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
> "I never lose. I either win or learn" - Nelson Mandela

Re: Curious Cloudflare DNS behavior

[Rubens Kuhl]

>
>
>
> Outsourcing stuff like DNS is just a continuation of the trend of sending
> your workloads onto someone else's cloud.  It seems easy -- right up until
> it isn't working the way you want it to.
>
>
Outsourcing DNS recursion isn't a good trade-off IMHO, but outsourcing
threat blocking via DNS is. So, my preferred recursive DNS setup is:
- Caching recursive server on ISP's premises
- Unbound or Knot Resolver based
- Root zone authoritatives to increase both privacy and performance
- Recursion done only for CDN zones (1e100.net, akadns.net etc.) in order
to get the best CDN performance for the access customers
- Forwarding of all non-CDN traffic to security-focused DNS recursives link
Umbrella, Cloudflare, Norton, Quad-9 etc.
- IGP-based anycast

This is also flexible enough to deal with DNSSEC signature expiration, AA
missing on authoritative responses etc., either by configuration on the
recursives themselves or by forwarding specific domains to specific outside
recursives.

Maintaining it requires work, it's not a plug and forget solution; but it
provides a good balance of performance, security and operational
flexibility.


Rubens

Re: Curious Cloudflare DNS behavior

[Joe Greco]

On Sat, May 30, 2020 at 01:52:58PM -0500, Constantine A. Murenin wrote:
> When you're not paying for service, you're not the customer, you're the
> product.

A pleasantly misleading statement.  Most easily observed in that there are
many cases where there is multiple monetization.  You may be your broadband
provider's customer, but it's likely they're still selling you in other
ways.  On the flip side, some of us provide free services with no ulterior
motive.  Go figure.

> I don't understand why anyone, especially anyone frequenting NANOG, would
> use Cloudflare for their DNS.

The early '90's called and said you're missing (don't worry, they said
it about me too).  :-)  ;-)

The Internet didn't evolve in the way its designers expected.  Early 
mistakes and errors required terrible remediation.  As an example, look
at the difficulty involved in running a service like e-mail or DNS.
E-mail requires all sorts of things to interoperate well, including SPF,
DKIM, SSL, DNSBL's, etc., etc., and it is a complicated service to run
self-hosted.  DNS is only somewhat better, with the complexity of DNSSEC
and other recent developments making for more difficulties in maintaining
self-hosted services.

Some people want basic services that "just work" without having to put
any effort into them.  That isn't limited to non-technical users.

Outsourcing stuff like DNS is just a continuation of the trend of sending
your workloads onto someone else's cloud.  It seems easy -- right up until
it isn't working the way you want it to.

But for most people, even those frequenting NANOG, maybe they just don't
want to go set up their own recursion nameservice.  I'm not saying I
agree with that strategy, but at least it's understandable.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Re: Curious Cloudflare DNS behavior

[Ryan Hamel]

Hey Constantine,

John came in with a technical issue. If you have nothing worthy to say about it 
specifically, it's best to keep quiet.
Thanks!
Ryan
On May 30 2020, at 11:52 am, Constantine A. Murenin  wrote:
> When you're not paying for service, you're not the customer, you're the 
> product.
>
> I don't understand why anyone, especially anyone frequenting NANOG, would use 
> Cloudflare for their DNS.
>
> Cloudflare runs a racket business, and their whole business model depends on 
> them being a monopoly; plus people buying into the vapourware that they 
> offer. When have monopolies been good for any industry? There's plenty of 
> evidence of Cloudflare 1.1.1.1 not working correctly; I'm sure one of their 
> employees (or the CTO!) will show up shortly to say otherwise!
>
> C.
> On Fri, 29 May 2020 at 12:31, John Sage  (mailto:js...@finchhaven.com)> wrote:
> > FULL DISCLOSURE: this is an end-user issue, but one that might have some
> > operational relevance, particularly if anyone from Cloudflare DNS is on
> > the list
> >
> > EXECUTIVE SUMMARY: twice in six weeks Cloudflare DNS on my new Netgear
> > Orbi cable modem/mesh WiFi hotspot has completely lost track of one (and
> > only one that I know of) prominent US domain: usbank dot com
> >
> > Internet provider: Comcast/Xfinity "Extreme Pro+"
> > Dynamic IP address via Comcast that hasn't changed in six-seven years
> > New Netgear Orbi cable modem, configured with DNS through Cloudflare
> > (1.1.1.1 and 1.0.0.1)
> >
> > Again, twice in 6 weeks Cloudflare DNS seems to loose complete track of
> > usbank dot com as a domain
> >
> > Symptoms: Firefox on Ubuntu Linux returns that little puzzled dinosaur
> > cartoon thing and "We can't seem to find this website right now"
> >
> > BUT ALSO:
> > Each one of ping, traceroute, dig and host returns
> > Host usbank . com not found: 2(SERVFAIL)
> > or some variant thereof
> > Everything else works "just fine" as the saying goes
> > And the Cloudflare DNS drop lasted for days the first time around
> > I can switch over to Google DNS (8.8.8.8 and 8.4.4.8) in the Orbi and
> > immediately fix the problem
> >
> > So. Seems odd that Cloudflare DNS would apparently loose complete track
> > of a major US domain name like usbank dot com
> >
> > Or am I missing something?
> >
> > - John
> > --
> > John Sage
> > FinchHaven Digital Photography
> > Email: js...@finchhaven.com (mailto:js...@finchhaven.com)
> > Web: https://finchhaven.smugmug.com/
> > Old web: http://www.finchhaven.com/
>
>
>

Re: Curious Cloudflare DNS behavior

[Saku Ytti]

[This post may portray opinions as facts, click to see the post]

On Sat, 30 May 2020 at 21:55, Constantine A. Murenin  wrote:
>
> When you're not paying for service, you're not the customer, you're the 
> product.
>
> I don't understand why anyone, especially anyone frequenting NANOG, would use 
> Cloudflare for their DNS.
>
> Cloudflare runs a racket business, and their whole business model depends on 
> them being a monopoly; plus people buying into the vapourware that they 
> offer.  When have monopolies been good for any industry?  There's plenty of 
> evidence of Cloudflare 1.1.1.1 not working correctly; I'm sure one of their 
> employees (or the CTO!) will show up shortly to say otherwise!
>
> C.
>
> On Fri, 29 May 2020 at 12:31, John Sage  wrote:
>>
>> FULL DISCLOSURE: this is an end-user issue, but one that might have some
>> operational relevance, particularly if anyone from Cloudflare DNS is on
>> the list
>>
>> EXECUTIVE SUMMARY: twice in six weeks Cloudflare DNS on my new Netgear
>> Orbi cable modem/mesh WiFi hotspot has completely lost track of one (and
>> only one that I know of) prominent US domain: usbank dot com
>>
>> Internet provider: Comcast/Xfinity "Extreme Pro+"
>>
>> Dynamic IP address via Comcast that hasn't changed in six-seven years
>>
>> New Netgear Orbi cable modem, configured with DNS through Cloudflare
>> (1.1.1.1 and 1.0.0.1)
>>
>> Again, twice in 6 weeks Cloudflare DNS seems to loose complete track of
>> usbank dot com as a domain
>>
>> Symptoms: Firefox on Ubuntu Linux returns that little puzzled dinosaur
>> cartoon thing and "We can't seem to find this website right now"
>>
>> BUT ALSO:
>>
>> Each one of ping, traceroute, dig and host returns
>>
>> Host usbank . com not found: 2(SERVFAIL)
>>
>> or some variant thereof
>>
>> Everything else works "just fine" as the saying goes
>>
>> And the Cloudflare DNS drop lasted for days the first time around
>>
>> I can switch over to Google DNS (8.8.8.8 and 8.4.4.8) in the Orbi and
>> immediately fix the problem
>>
>> So. Seems odd that Cloudflare DNS would apparently loose complete track
>> of a major US domain name like usbank dot com
>>
>> Or am I missing something?
>>
>>
>> - John
>> --
>> John Sage
>> FinchHaven Digital Photography
>> Email: js...@finchhaven.com
>> Web: https://finchhaven.smugmug.com/
>> Old web: http://www.finchhaven.com/
>>
>>
>


-- 
  ++ytti

Re: Curious Cloudflare DNS behavior

[Constantine A. Murenin]

When you're not paying for service, you're not the customer, you're the
product.

I don't understand why anyone, especially anyone frequenting NANOG, would
use Cloudflare for their DNS.

Cloudflare runs a racket business, and their whole business model depends
on them being a monopoly; plus people buying into the vapourware that they
offer.  When have monopolies been good for any industry?  There's plenty of
evidence of Cloudflare 1.1.1.1 not working correctly; I'm sure one of their
employees (or the CTO!) will show up shortly to say otherwise!

C.

On Fri, 29 May 2020 at 12:31, John Sage  wrote:

> FULL DISCLOSURE: this is an end-user issue, but one that might have some
> operational relevance, particularly if anyone from Cloudflare DNS is on
> the list
>
> EXECUTIVE SUMMARY: twice in six weeks Cloudflare DNS on my new Netgear
> Orbi cable modem/mesh WiFi hotspot has completely lost track of one (and
> only one that I know of) prominent US domain: usbank dot com
>
> Internet provider: Comcast/Xfinity "Extreme Pro+"
>
> Dynamic IP address via Comcast that hasn't changed in six-seven years
>
> New Netgear Orbi cable modem, configured with DNS through Cloudflare
> (1.1.1.1 and 1.0.0.1)
>
> Again, twice in 6 weeks Cloudflare DNS seems to loose complete track of
> usbank dot com as a domain
>
> Symptoms: Firefox on Ubuntu Linux returns that little puzzled dinosaur
> cartoon thing and "We can't seem to find this website right now"
>
> BUT ALSO:
>
> Each one of ping, traceroute, dig and host returns
>
> Host usbank . com not found: 2(SERVFAIL)
>
> or some variant thereof
>
> Everything else works "just fine" as the saying goes
>
> And the Cloudflare DNS drop lasted for days the first time around
>
> I can switch over to Google DNS (8.8.8.8 and 8.4.4.8) in the Orbi and
> immediately fix the problem
>
> So. Seems odd that Cloudflare DNS would apparently loose complete track
> of a major US domain name like usbank dot com
>
> Or am I missing something?
>
>
> - John
> --
> John Sage
> FinchHaven Digital Photography
> Email: js...@finchhaven.com
> Web: https://finchhaven.smugmug.com/
> Old web: http://www.finchhaven.com/
>
>
>

Re: AS hijacking (Philosophy, rants, GeoMind)

[William Herrin]

On Fri, May 29, 2020 at 8:40 AM Justin Wilson (Lists)  wrote:
> Here is where the philosophy comes into play.  The very terse e-mail we 
> received back was basically “As2 gets hijacked a lot and it’s not our 
> problem”. So my question for the NANOG folks.  At what point do you say “it’s 
> not your problem” when it involves your ASN?

The point where someone who isn't you is both hijacking your ASN *and*
someone else's prefix? Have you confirmed that the hijack actually
came from UDel, that the AS path matches one that's legitimate for
UDel? The guy hijacking your route doesn't have to list just one AS as
the origin; he can' list an entire chain.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: AS hijacking (Philosophy, rants, GeoMind)

[Mark Milhollan]

On Fri, 29 May 2020, Justin Wilson (Lists) wrote:

One of the companies I work for recently had an issue with AS 2 
(University of Delaware) hijacking a prefix.


Sounds like a misconfigured prepend, someone thinking the value to 
provide is the number of prepends instead of the ASN to prepend.



/mark

Re: Curious Cloudflare DNS behavior

[Mark Milhollan]

On Fri, 29 May 2020, John Sage wrote:


Each one of ping, traceroute, dig and host returns

Host usbank . com not found: 2(SERVFAIL)


Could be a DNSSEC issue.  When it happens check  or 
 to see if that's the case.


--
Mark Milhollan
+1-805-901-4009

Clueful Domain Name Expert from Network Solutions Needed

[james jones]

Greetings,

Hope everyone is staying healthy and safe. I am really looking for help
from someone clueful at Network Solutions. I am having major issues with
transferring a domain away from them. Turns out the primary contact on the
account has been the same for over a 15+ years. That person has not been
involved with the organization for decade and was never updated. I have
been getting the run around from customer service to for 4 months trying to
update the primary contact. I have provided all the information that has
been requested multiple times . Is there anyone on the list that might be
able to help.

P.S. Sorry for have to do this here.

-James

Re: Contact at Ubiquiti Networks?

[Etienne-Victor Depasquale]

I disagree with your certainty, Saku. That's best left to results in
papers, as you correctly point out.



On Wed, May 27, 2020 at 9:07 AM Saku Ytti  wrote:

>
>
> On Wed, 27 May 2020 at 10:00, Mel Beckman  wrote:
>
> Hertz car rental has the #1 product in its industry, even its major
>> competitor Avis agrees (“We’re number two“:-), and yet Hertz stock is
>> plunging towards zero even as we speak. Stock price has nothing to do with
>> product quality. Theranos, for example, had a completely fictional product,
>> yet it stock price skyrocketed.
>>
>
> I agree with the sentiment that stock value cannot be used to glean
> ~anything, certainly not something specific like 'marketability of
> product'. I'd be interested in reading paper where stock value is
> determined to be more reliable than random metric on anything except stock
> value.
>
> However Hertz depreciation is caused by the anticipation that debtors will
> receive almost all of the equity, diluting the current owners by massive
> ratio. The value tries to reflect post-dilution value. My Stetson-Harrision
> analysis tells that current owners will end up owning less than 20% of
> Hertz and more than 80% goes to debtors.
> So by that logic, 80% of Hertz value is currently not trading.
>
> --
>   ++ytti
>


-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale

Re: Contact at Ubiquiti Networks?

[Etienne-Victor Depasquale]

I disagree, Mel.

Your quoting of exceptions, even if they were correct, doesn't invalidate
the generalization that stock price is linked to product marketability.

You can think of it in terms of data science: product marketability is a
good predictor of stock price.

On Wed, May 27, 2020 at 8:57 AM Mel Beckman  wrote:

> Hertz car rental has the #1 product in its industry, even its major
> competitor Avis agrees (“We’re number two“:-), and yet Hertz stock is
> plunging towards zero even as we speak. Stock price has nothing to do with
> product quality. Theranos, for example, had a completely fictional product,
> yet it stock price skyrocketed.
>
> Stock price is simply a way of measuring the perceived market value of a
> company‘s earning potential.
>
>  -mel beckman
>
> On May 26, 2020, at 11:50 PM, Etienne-Victor Depasquale 
> wrote:
>
> 
> " stock value is a terribly inaccurate way to measure if a company is
> "excelling."  "
>
> That requires qualification.
>
> Stock value might be a "terribly inaccurate way" in the short term but in
> the long term, it reflects whether you have a marketable product or not.
>
> On Tue, May 26, 2020 at 4:20 PM Mike Hammett  wrote:
>
>> Kind of OT for NANOG, but stock value is a terribly inaccurate way to
>> measure if a company is "excelling." Wall Street knows nothing of how to
>> run a company, prioritizing quarterly profit over long-term success. Not
>> hiring additional staff makes your quarterly numbers look good, but it
>> isn't good for the long-term attractiveness of your product. A good
>> business doesn't just target new suckers, they also keep existing customers
>> happy. Eventually you run out of suckers and all you have is a bunch of
>> burned bridges in your wake.
>>
>> I subscribe to several feature requests in their community that are YEARS
>> old with little to no response from Ubiquiti. Some of them can't be hard
>> for Ubiquiti to implement because they're running on the exact same
>> hardware and underlying OS and some of them you can configure in JSON
>> files, but they just aren't available in the GUI. They just don't care.
>> They'd rather push out Flavor Flav cameras or lighting.
>>
>> They came out with a new product in a particular family and opened a new
>> feature request section for it. I commented something similar to, "Start
>> with feature parity with the existing product, then start working through
>> the years of feature requests there. Come back when you're done."
>>
>>
>> This doesn't just afflict equipment manufacturers. Network operators are
>> in the same boat. Both groups have companies profiting hundreds of millions
>> or billions of dollars every quarter, can't spare a few hundred grand a
>> year for a couple dev-ops guys to just bang out automation or features.
>> Yes, I understand you rarely get twice the work from twice the people, but
>> there are opportunities to make this better.
>>
>>
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>> 
>> 
>> 
>> 
>> Midwest Internet Exchange 
>> 
>> 
>> 
>> The Brothers WISP 
>> 
>> 
>> --
>> *From: *"Matt Hoppes" 
>> *To: *"Mike Hammett" 
>> *Cc: *"NANOG list" 
>> *Sent: *Tuesday, May 26, 2020 8:28:52 AM
>> *Subject: *Re: Contact at Ubiquiti Networks?
>>
>> Except, you could argue they are exceling.  Stocks are going up up up,
>> and folks buy the product.
>>
>> I really wish stock holders would ask the proper questions in the
>> quarterly calls.
>>
>> On 5/26/20 8:53 AM, Mike Hammett wrote:
>> > That is a big problem. In terms of their UniFi product line, there are
>> > no reasonable alternatives.
>> >
>> > Upper management is the biggest problem. They have severe ADD.
>> >
>> > A ton of companies have these kinds of issues. They just plain don't
>> > hire enough people in the right areas to really excel.
>> >
>> >
>> >
>> > -
>> > Mike Hammett
>> > Intelligent Computing Solutions 
>> > <
>> https://plus.google.com/+IntelligentComputingSolutionsDeKalb><
>> https://www.linkedin.com/company/intelligent-computing-solutions><
>> https://twitter.com/ICSIL>
>> > Midwest Internet Exchange 
>> > <
>> https://www.linkedin.com/company/midwest-internet-exchange><
>> https://twitter.com/mdwestix>
>> > The Brothers WISP 
>> > <
>> 

Re: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs)

[Etienne-Victor Depasquale]

Thank you Carsten, and thank you Pacal. Your replies are valuable and
packed with insight.

I'll wrap up with how I interpret RPL's behaviour in terms of IP hops.

On one hand, RFC6775 defines a route-over topology as follows:
"A topology where hosts are connected to the 6LBR through the use of
intermediate layer-3 (IP) routing.
Here, hosts are typically multiple IP hops away from a 6LBR.
The route-over topology typically consists of a 6LBR, a set of 6LRs, and
hosts."
If RPL is route-over by definition, then RFC6775 would imply that there are
typically multiple IP hops between a leaf and the border router.

On the other hand, there at least two contradictions (which I justify after
stating them):
(a) RFC6550 states that "RPL also introduces the capability to bind a
subnet together with a common prefix and to route within that subnet."
(b) Reduction of a DODAG to a single subnet prefix, albeit only only one
parent-child relationship deep, is clearly shown at Contiki-NG's Github
page (deep dive section).

The hinge on which my understanding revolves is that an IP hop traverses a
router and ***results in a change of prefix of the link on which the packet
travels*** :

-->
-->

With RPL, the "hop" would look like as shown below:

  --
--

There seems to be a change in the meaning associated with "IP hop".
I guess that I can reconcile both cases through the observation that RPL
actually does apply to a single, NBMA link and therefore the IP prefix
***is*** the same.
Then again, calling the RPL device involved in the packet forwarding by the
name "router" feels like an uncomfortable stretch.
Don't routers sit at the meeting point of different layer 2 links?


Cheers,

Etienne

On Fri, May 29, 2020 at 10:39 PM Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> Hello Etienne
>
> You may see ND as the host to * interface for any network and RPL as the
> router to router interface when the network is NBMA.
>
> Some of us cared about the interworking.
>
> Look at the RPL Unaware leaf I-draft and you’ll see that I’m sure.
>
> Keep safe,
>
> Pascal
>
> > Le 29 mai 2020 à 20:28, Carsten Bormann  a écrit :
> >
> > Hi Etienne,
> >
> > I’m also not sure many of the classical network operators assembled in
> NANOG work with 6LoWPANs today, but I still can answer your question.
> >
> >> While trying to build a holistic view of LoWPANs, I'm consulting the
> IETF's informational and standards documents.
> >>
> >> I'm struck by the impression that, despite the significance of
> RFC6775's extension of Neighbor Discovery(ND) to low-power and lossy
> networks (LLNs),
> >> it is largely ignored by RFC6550 (RPL), with little to no reference to
> the ontological plane created in RFC6775's terminology section.
> >
> > Yes, you could say that.
> >
> > ND (Neighbor discovery) describes interfaces between hosts and between
> hosts and routers.
> > 6LoWPAN-ND does not use host-to-host interfaces (different from
> Ethernet, all traffic goes over routers, which RFC 4861 already forsaw in
> the L — on-link — bit, which isn’t set in 6LoWPAN-ND).
> >
> > RFC 6550 was completed at a time when many people who came in from the
> WSN (wireless sensor network) world thought they could get away with a
> network that is wholly composed of routers.
> > Even the “leaf” nodes in the RPL world were participating in the routing
> protocol and therefore didn’t really need a host-router interface.  There
> was no separate host-router interface in that world, because there were no
> non-router hosts.
> >
> >> (a) router advertisements and router solicitations are substituted by
> DAG information objects (DIO) and DAG information solicitations (DIS)
> >
> > Right, DIO and DAO are router-to-router messages.  If there are no hosts
> (and routers don’t bootstrap themselves as hosts), you don’t need ND.
> >
> >> (b) the terms "mesh-under" and "route-over" (widely cited), defined in
> RFC6775, are absent from RFC6550
> >
> > RFC6550 is route over by definition.  Actually, the term was coined by
> the people working closely with the RPL development; RFC 6775 does
> appropriate it as 6LoWPAN-ND is applicable in either case.
> >
> >> (c) jarringly: RFC6775 describes the route-over topologies as
> multi-IP-hop, while RFC6550 gathers DODAG nodes within the confines of the
> same IPv6 prefix as their border router - no multiple IP hops.
> >
> > I’m not sure where you get this interpretation: RFC 6550 (RPL) is very
> much about IP hops.
> > Maybe you mean the address architecture that was defined explicitly in
> RFC 6775; RFC 6550 does not really say much about addresses.
> >
> > Note that the RPL people have since proceeded to (at least partially)
> embrace the host-router concept from the IP architecture; RFC 8505 is an
> update to RFC 6775 that makes 6LoWPAN-ND more palatable to RPL people.
> >
> > I have CCed Pascal Thubert who, as a co-author to all three RFCs,
> certainly will have another perspective on