- NANOG - lists.nanog.org

Verizon Wireless
by Mark Stevens 02 Jun '20

02 Jun '20

Good morning, If a Verizon Wireless engineer covering NJ/NYC could contact me offline it would be much appreciated. We are currently seeing one way voice paths from VZW in 3 NJ tandems. Thanks Mark

1 0

Contact at Ubiquiti Networks?
by j k 02 Jun '20

02 Jun '20

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

9 9

Re: Contact at Ubiquiti Networks?
by Mike Hammett 01 Jun '20

01 Jun '20

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 Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Ben P" <bp(a)list-subs.com> To: "Mike Hammett" <nanog(a)ics-il.net> Cc: "j k" <jsklein(a)gmail.com>, "NANOG list" <nanog(a)nanog.org> Sent: Tuesday, May 26, 2020 5:01:36 AM Subject: Re: Contact at Ubiquiti Networks? Agree 1000% with the sentiments expressed by Mike. Unfortunately despite much research I’ve been unable to find a suitable replacement vendor. All the other vendors seem to want to ram cloud-management down your throat which I absolutely do not want. My network, my control, not under the auspices of someone else’s magic cloud. On 25 May 2020, at 21:21, Mike Hammett < nanog(a)ics-il.net > wrote: 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 Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "j k" < jsklein(a)gmail.com > To: "NANOG list" < nanog(a)nanog.org > 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

16 24

RE: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs)
by Templin (US), Fred L 01 Jun '20

01 Jun '20

NBMA is not necessarily a one-size-fits-all category, and it looks like multiple proposals are considering models for NBMA links. AERO and OMNI define an NBMA link model for virtual links and do define the operation of IPv6 ND over those links in ways that go beyond RFC5942. This is encouraged in RFC4861 where it says: “Unless specified otherwise (in a document that covers operating IP over a particular link type) this document applies to all link types. However, because ND uses link-layer multicast for some of its services, it is possible that on some link types (e.g., Non-Broadcast Multi-Access (NBMA) links), alternative protocols or mechanisms to implement those services will be specified (in the appropriate document covering the operation of IP over a particular link type).” Fred From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Monday, June 01, 2020 7:27 AM To: Wes Beebee (wbeebee) <wbeebee=40cisco.com(a)dmarc.ietf.org>; Etienne-Victor Depasquale <edepa(a)ieee.org> Cc: NANOG <nanog(a)nanog.org>; ipv6(a)ietf.org Subject: RE: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs) I take the “there was no NBMA” off, then, Wes, you’re correct. I’ll add a ref to RFC 5942 in section 4.4 that discusses the use of on-link flag. Note that Hub and spoke is a very limited conception of NBMA. Think of an IOT network such as a RPL domain, or a frame relay network with OSPFv2 NBMA / P2MP models. It takes quite a bit more than resetting the on-link flag to enable IPv6 ND on those NBMA networks, though it is indeed necessary. This is what I tried to express too concisely. Keep safe, Pascal PS For NBMA, RFC 4861 clearly says non-broadcast multiple access (NBMA) - Redirect, Neighbor Unreachability Detection and next-hop determination should be implemented as described in this document. Address resolution, and the mechanism for delivering Router Solicitations and Advertisements on NBMA links are not specified in this document. Note that if hosts support manual configuration of a list of default routers, hosts can dynamically acquire the link-layer addresses for their neighbors from Redirect messages. From: Wes Beebee (wbeebee) <wbeebee=40cisco.com(a)dmarc.ietf.org<mailto:wbeebee=40cisco.com@dmarc.ietf.org>> Sent: lundi 1 juin 2020 16:00 To: Pascal Thubert (pthubert) <pthubert(a)cisco.com<mailto:pthubert@cisco.com>>; Etienne-Victor Depasquale <edepa(a)ieee.org<mailto:edepa@ieee.org>> Cc: NANOG <nanog(a)nanog.org<mailto:nanog@nanog.org>>; ipv6(a)ietf.org<mailto:ipv6@ietf.org> Subject: Re: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs) RFC 5942 outlines how NBMA works with Neighbor Discovery. Using this RFC, IPv6 has been deployed in NBMA networks (DOCSIS) with 10 million+ subscribers without any problems. - Wes From: ipv6 <ipv6-bounces(a)ietf.org<mailto:ipv6-bounces@ietf.org>> on behalf of "Pascal Thubert (pthubert)" <pthubert=40cisco.com(a)dmarc.ietf.org<mailto:pthubert=40cisco.com@dmarc.ietf.org>> Date: Sunday, May 31, 2020 at 8:29 AM To: Etienne-Victor Depasquale <edepa(a)ieee.org<mailto:edepa@ieee.org>> Cc: NANOG <nanog(a)nanog.org<mailto:nanog@nanog.org>>, "ipv6(a)ietf.org<mailto:ipv6@ietf.org>" <ipv6(a)ietf.org<mailto:ipv6@ietf.org>> Subject: Re: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs) Cool, that’s the whole point. With IPv6 ND as defined 20+ years ago there couldn’t be NBMA and there couldn’t be MLSN. We have changed that in IoT and we are now trying to generalize to all types of links. There’s a tentative to get the aforementioned draft adopted at 6MAN. If you found it useful please voice support ! Take care, Pascal Le 31 mai 2020 à 13:11, Etienne-Victor Depasquale <edepa(a)ieee.org<mailto:edepa@ieee.org>> a écrit : Pascal, thank you, the draft at https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ is very informative. You hit the nail on the head with your suggestion of confusion between the congruence of link and subnet. However, I followed one of the references (RFC4903) in your draft and it does not help that it (RFC4903) points to RFC4291's assertion that: "Currently IPv6 continues the IPv4 model that a subnet prefix is associated with one link" RFC4903 further states that: "clearly, the notion of a multi-link subnet would be a change to the existing IP model.". I confess: your assertion in the draft that: "In Route-Over Multi-link subnets (MLSN) [RFC4903], routers federate the links between nodes that belong to the subnet, the subnet is not on-link and it extends beyond any of the federated links" is news to me. Best regards, Etienne On Sat, May 30, 2020 at 1:39 PM Pascal Thubert (pthubert) <pthubert(a)cisco.com<mailto:pthubert@cisco.com>> wrote: Hello Etienne Victor Maybe you’re confusing link and a subnet? This is discussed at length here: https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ RPL can route inside a subnet using host routes. This is how a multi link subnet can be made to work... Please let me know if the draft above helped and whether it is clear enough. The best way for that discussion would be to cc 6MAN. Keep safe, Pascal Le 30 mai 2020 à 10:03, Etienne-Victor Depasquale <edepa(a)ieee.org<mailto:edepa@ieee.org>> a écrit : 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*** : --------<incoming packet; link prefix = p1>------><router> --------<outgoing packet; link prefix = p2>------> With RPL, the "hop" would look like as shown below: --------<incoming packet; link prefix = p1>------<router> --------<outgoing packet; link prefix = p1>------ 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) <pthubert(a)cisco.com<mailto:pthubert@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 <cabo(a)tzi.org<mailto:cabo@tzi.org>> 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 this. > > Grüße, Carsten > -- 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 -- 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

1 0

FW: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs)
by Pascal Thubert (pthubert) 01 Jun '20

01 Jun '20

I take the “there was no NBMA” off, then, Wes, you’re correct. I’ll add a ref to RFC 5942 in section 4.4 that discusses the use of on-link flag. Note that Hub and spoke is a very limited conception of NBMA. Think of an IOT network such as a RPL domain, or a frame relay network with OSPFv2 NBMA / P2MP models. It takes quite a bit more than resetting the on-link flag to enable IPv6 ND on those NBMA networks, though it is indeed necessary. This is what I tried to express too concisely. Keep safe, Pascal PS For NBMA, RFC 4861 clearly says non-broadcast multiple access (NBMA) - Redirect, Neighbor Unreachability Detection and next-hop determination should be implemented as described in this document. Address resolution, and the mechanism for delivering Router Solicitations and Advertisements on NBMA links are not specified in this document. Note that if hosts support manual configuration of a list of default routers, hosts can dynamically acquire the link-layer addresses for their neighbors from Redirect messages. From: Wes Beebee (wbeebee) <wbeebee=40cisco.com(a)dmarc.ietf.org<mailto:wbeebee=40cisco.com@dmarc.ietf.org>> Sent: lundi 1 juin 2020 16:00 To: Pascal Thubert (pthubert) <pthubert(a)cisco.com<mailto:pthubert@cisco.com>>; Etienne-Victor Depasquale <edepa(a)ieee.org<mailto:edepa@ieee.org>> Cc: NANOG <nanog(a)nanog.org<mailto:nanog@nanog.org>>; ipv6(a)ietf.org<mailto:ipv6@ietf.org> Subject: Re: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs) RFC 5942 outlines how NBMA works with Neighbor Discovery. Using this RFC, IPv6 has been deployed in NBMA networks (DOCSIS) with 10 million+ subscribers without any problems. * Wes From: ipv6 <ipv6-bounces(a)ietf.org<mailto:ipv6-bounces@ietf.org>> on behalf of "Pascal Thubert (pthubert)" <pthubert=40cisco.com(a)dmarc.ietf.org<mailto:pthubert=40cisco.com@dmarc.ietf.org>> Date: Sunday, May 31, 2020 at 8:29 AM To: Etienne-Victor Depasquale <edepa(a)ieee.org<mailto:edepa@ieee.org>> Cc: NANOG <nanog(a)nanog.org<mailto:nanog@nanog.org>>, "ipv6(a)ietf.org<mailto:ipv6@ietf.org>" <ipv6(a)ietf.org<mailto:ipv6@ietf.org>> Subject: Re: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs) Cool, that’s the whole point. With IPv6 ND as defined 20+ years ago there couldn’t be NBMA and there couldn’t be MLSN. We have changed that in IoT and we are now trying to generalize to all types of links. There’s a tentative to get the aforementioned draft adopted at 6MAN. If you found it useful please voice support ! Take care, Pascal Le 31 mai 2020 à 13:11, Etienne-Victor Depasquale <edepa(a)ieee.org<mailto:edepa@ieee.org>> a écrit : Pascal, thank you, the draft at https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ is very informative. You hit the nail on the head with your suggestion of confusion between the congruence of link and subnet. However, I followed one of the references (RFC4903) in your draft and it does not help that it (RFC4903) points to RFC4291's assertion that: "Currently IPv6 continues the IPv4 model that a subnet prefix is associated with one link" RFC4903 further states that: "clearly, the notion of a multi-link subnet would be a change to the existing IP model.". I confess: your assertion in the draft that: "In Route-Over Multi-link subnets (MLSN) [RFC4903], routers federate the links between nodes that belong to the subnet, the subnet is not on-link and it extends beyond any of the federated links" is news to me. Best regards, Etienne On Sat, May 30, 2020 at 1:39 PM Pascal Thubert (pthubert) <pthubert(a)cisco.com<mailto:pthubert@cisco.com>> wrote: Hello Etienne Victor Maybe you’re confusing link and a subnet? This is discussed at length here: https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ RPL can route inside a subnet using host routes. This is how a multi link subnet can be made to work... Please let me know if the draft above helped and whether it is clear enough. The best way for that discussion would be to cc 6MAN. Keep safe, Pascal Le 30 mai 2020 à 10:03, Etienne-Victor Depasquale <edepa(a)ieee.org<mailto:edepa@ieee.org>> a écrit : 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*** : --------<incoming packet; link prefix = p1>------><router> --------<outgoing packet; link prefix = p2>------> With RPL, the "hop" would look like as shown below: --------<incoming packet; link prefix = p1>------<router> --------<outgoing packet; link prefix = p1>------ 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) <pthubert(a)cisco.com<mailto:pthubert@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 <cabo(a)tzi.org<mailto:cabo@tzi.org>> 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 this. > > Grüße, Carsten > -- 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 -- 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

1 0

AS hijacking (Philosophy, rants, GeoMind)
by Justin Wilson (Lists) 01 Jun '20

01 Jun '20

One of the companies I work for recently had an issue with AS 2 (University of Delaware) hijacking a prefix. Due to Origin AS, good upstreams, and the like this has not really affected the traffic to the legit blocks. However, GeoMind picked this up almost immediately it seems. The IP blocks when you go to speedtest.net come back to the university of Delaware. This seems to be the only issue at the moment so we are working through contacting the peers of AS2 and asking them to look into this. We had also contacted University of Delaware. 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? Rant I almost always have issues with GeoMind and others when it comes to IP space. Several of my folks have received allocations from Arin in March. A few are still fighting with geolocation stuff with a few of the providers. So why does GeoMind atomically accept a hijacked prefix as correct? All the right boxes have been ticked. Origin Validiation, registry sets, etc. Happy Friday! Justin Wilson j2sw(a)mtin.net — https://j2sw.com - All things jsw (AS209109) https://blog.j2sw.com - Podcast and Blog

7 7

Curious Cloudflare DNS behavior
by John Sage 31 May '20

31 May '20

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: jsage(a)finchhaven.com Web: https://finchhaven.smugmug.com/ Old web: http://www.finchhaven.com/

9 10

Rate-limiting BCOP?
by Bryan Holloway 31 May '20

31 May '20

I'm curious if the community would be willing to share their best-practices and/or recommendations and thoughts on how they handle situations where a customer buys X amount of bandwidth, but the physical link is capable of Y, where Y > X. (Yes, I speak of policy-maps, tx/rx-queues, etc.) For example, it might be arguably common to aggregate customer links Layer 2, and then push them upstream to where they anchor Layer 3. That Layer 2 <-> Layer 3 could be a couple of meters or several kilometers. So, as I see it, my options are: * Rate-limit at the Layer 2 switch for both customer ingress/egress, * Rate-limit at the Layer 3 router upstream, i/e, or * Some combination thereof? E.g.: Rate-limit my traffic towards the customer closer to the core, and rate-limit ingress closer to the edge? I've done all three on some level in my travels, but in the past it's also been oftentimes vendor-centric which hindered a scalable or "templateable" solution. (Some things police in only one direction, or only well in one direction, etc.) In case someone is interested in a tangible example, imagine an Arista switch and an ASR9k router. :) Thoughts?

5 8

Re: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs)
by Etienne-Victor Depasquale 31 May '20

31 May '20

Pascal, thank you, the draft at https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ is very informative. You hit the nail on the head with your suggestion of confusion between the congruence of link and subnet. However, I followed one of the references (RFC4903) in your draft and it does not help that it (RFC4903) points to RFC4291's assertion that: "Currently IPv6 continues the IPv4 model that a subnet prefix is associated with one link" RFC4903 further states that: "clearly, the notion of a multi-link subnet would be a change to the existing IP model.". I confess: your assertion in the draft that: "In Route-Over Multi-link subnets (MLSN) [RFC4903], routers federate the links between nodes that belong to the subnet, the subnet is not on-link and it extends beyond any of the federated links" is news to me. Best regards, Etienne On Sat, May 30, 2020 at 1:39 PM Pascal Thubert (pthubert) < pthubert(a)cisco.com> wrote: > Hello Etienne Victor > > Maybe you’re confusing link and a subnet? > > This is discussed at length here: > > https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ > > RPL can route inside a subnet using host routes. This is how a multi link > subnet can be made to work... > > Please let me know if the draft above helped and whether it is clear > enough. The best way for that discussion would be to cc 6MAN. > > Keep safe, > > Pascal > > Le 30 mai 2020 à 10:03, Etienne-Victor Depasquale <edepa(a)ieee.org> a > écrit : > > > 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*** : > > --------<incoming packet; link prefix = p1>------><router> > --------<outgoing packet; link prefix = p2>------> > > With RPL, the "hop" would look like as shown below: > > --------<incoming packet; link prefix = p1>------<router> > --------<outgoing packet; link prefix = p1>------ > > 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) < > pthubert(a)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 <cabo(a)tzi.org> 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 this. >> > >> > Grüße, Carsten >> > >> > > > -- > 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 > > -- 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

1 0

Clueful Domain Name Expert from Network Solutions Needed
by james jones 30 May '20

30 May '20

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

1 0