Re: Rogers 2022 network outage, Xona Report

[Victor Kuarsingh]

Jean-Francois,

Comments in line.

On Fri, Aug 2, 2024, 22:59 Jean-Francois Mezei 
wrote:

> On 2024-08-02 21:39, Jean-Francois Mezei wrote:
>
> > Following process, redacted portions of the XONA Partners report have
> > been published.
> >
> > https://crtc.gc.ca/otf/eng/2022/8000/c12-202203868.htm
>
>
> I have some question on terminology: (pardon my newbieness, just wanting
> to be pedantic on terminology).
>
>
>
> "Rogers staff removed the Access Control List policy filter from the
> configuration of the distribution routers. This consequently resulted in
> a flood of IP routing information into the core network routers, which
> triggered the outage."
>
> The report mentions Rogers uses IS-IS as interior routing protocol buit
> i'll use the more generic OSPF bellow.
>
>
> Assumtion here is that only IS-IS or OSPF is used.  In a dual stack
> network, its possible both are used - one for each protocol family .


> Questions:
>
> 1- I had always heard of routers facing the Internet (and thus doing
> BGP) as "edge" or "border".   Is the term "distribution router" common
> in the industry
>

The term was common 20+ years ago.  Core / distribution  / access - being
common legacy terms.



> 2- When a border/edge router receives some 980,000 route entries from
> the transit provider, aren't those packets addressed to the IP address
> of that edge router with port 179 and going to the router's internal BGP
> process instead of being routed?   (report makes it look those packets
> were left to run wild and propagate onto the intranet due to lack of ACL).
>
> Internet edge is not the only edge in complex operator networks.  Often
> services are colorated in central areas if a network.  These area may not
> be eBGP but rather iBGP.



>
>
>
> Would the rules that define which BGP routes are to be converted to OSPF
> and then propagated to OSPF peers on the intranet be called an "Access
> Control List"?  If not, what would they be called? (routing policy filter?)
>
>
> No. Doubt anyone actually exports bgp to igp anymore.  ACLs are often used
> for route policy.
>
>
>
> (I have always though of ACL as a packet routing rule, not of route
> building one).
>
> Would it be fair to state that a large ISP network would use BGP to OSPF
> route propagation to load balance upload-heavy site?  BGP1 advertises
> itself to OSPF-A B and C as the router to talk to for packets desined to
> upload-heavy site,  while BGP2 does the same for internal routers OSPF-D
> E and F?
>
> (Just trying to understand the scope of route information that Rogers's
> BGP routers would want to send to the internal routing protocol.
>
>
> In short.  The way the report was written,  you will not be able to
> decipher what actually happened.


>
>
> Thanks in advance for any precisions on the above. Just want to make
> sure I puch right when I make requests for disclosure of the redacted
> portions.
>


Victor K

>
>

Re: RFC6598 100.64/10: to bogon or not to bogon (team-cymru et all)

[Victor Kuarsingh]

On Wed, Mar 8, 2023 at 7:43 AM Lukas Tribus  wrote:

> > The think that you have to remember to do is to exclude locally
> > significant (100.64/10, RFC 1918, et al.) from those filters /or/
> > account for them in another way.
>
> You know all this if you are the network operator.
>
> If you are the customer of the ISP, let's say a datacenter/cloud
> customer and you are deploying Web or Mailservices, you have no idea
> whether this ISP will route RFC6598 traffic to you or not and you
> certainly will not get informed by the ISP if that ever changes. You
> only know about this once you are dropping production traffic from
> clients in 100.64/10 and a trouble ticket has found it's way to you
> ("residential customers of the same ISP can't reach your cloud
> services").
>
> That is why RFC6598 is suggesting to drop this traffic on autonomous
> system borders. The RFC is not suggesting to drop this traffic
> elsewhere.
>

This was the intention of the RFC.  As this space was intended to be used
with an AS's network to service CGN needs.  That CGN boundary likely ends
before a given customer and/or neighboring network, so it would make sense
that downstream and neighboring networks would filter at their borders.
All that said, if for some reason, a downstream network has 100.64/10
assigned to direct links on an interconnection, that may be a problem.
That type of deployment model was not within the intention of RFC6598
(using the block for non-CGN use cases).

Trying to block RFC6598 at the host level can potentially be problematic as
the network that host is connected to may be using RFC6598 space.


>
>
> > Bogons is just a list of IPs that shouldn't be on the open Internet.
>
> Which, for RFC6598 is misleading because RFC6598 space is used within
> (but not beyond) ISP networks. "The internet" includes ISP networks.
>

It is true an ISP's network would be part of the Internet, but the part
which is servicing CGN zones would not part of the generally reachable part
of the Internet (inbound, all ports, all protocols).   The CGN zone within
the ISP network is as much part of the Internet as a home network would be
(non-routable addresses used to service an upstream NAT).

Victor Kuarsingh



>
>
> > The Team Cymru bogon's list is a tool and like all tools, it can be
> > mis-used and become a foot gun.
>
> Which is why proper description, documentation and education is important.
>
>
>
> Thanks,
> Lukas
>

Re: Rogers outage - House of Commons INDU hearing

[Victor Kuarsingh]

Let's see how this goes.  A political hearing will (IMO) likely not resolve
in the identification of core technical issues nor meaningful changes to
avoid what was experienced on July 8th.   A third party conducting a real
technical investigation is likely the way to find a RCA and set of
recommendations.

regards,

Victor K

On Mon, Jul 25, 2022 at 8:56 PM Sean Donelan  wrote:

> Canada is part of North America, and may be of interest to NANOG.
>
> Rogers had a nationwide outage on July 8, 2022.  The House of Commons
> held a hearing today (July 25, 2022) on the outage and invited the Rogers
> CEO, other company CEOs, regulators and academics to testify.
>
> Recording of the House of Commons INDU hearing
>
> https://www.ourcommons.ca/Committees/en/INDU
>
> Rogers CEO Tony Staffieri said the company now plans to physically
> separate its wireless and internet networks to ensure more redundancy in
> the future. Company estimates it will cost at least $250 million.
>
> Rogers still plans to complete the proposed $26-billion acquisition of
> Shaw.  The CEO claimed the greater scale of the merged companies would
> allow Rogers to create seperate wireless and internet networks faster.
>
> CRTC chairperson said that reliability and competition are separate
> issues.
>
>
> Department of Industry
> • Simon Kennedy, Deputy Minister
> • Éric Dagenais, Senior Assistant Deputy Minister, Spectrum and
> Telecommunications Sector
> • Mark Schaan, Senior Assistant Deputy Minister, Strategy and Innovation
> Policy Sector
>
> Rogers Communications Inc.
> • Tony Staffieri, President and Chief Executive Officer
> • Ron McKenzie, Chief Technology and Information Officer
> • Ted Woodhead, Chief Regulatory Officer and Government Affairs
>
> Canadian Radio-television and Telecommunications Commission
> • Ian Scott, Chairperson and Chief Executive Officer
> • Fiona Gilfillan, Executive Director, Telecommunications
> • Michel Murray, Director, Dispute Resolution and Regulatory
> Implementation, Telecommunications
>
> As an individual
> • Michael Geist, Canada Research Chair in Internet and E-Commerce Law,
> Faculty of Law, University of Ottawa
> • Ben Klass, PhD Candidate, Carleton University, Senior Research
> Associate, Canadian Media Concentration Research Project
> • Dwayne Winseck, Professor, Carleton University, Director, Global Media
> and Internet Concentration Project
>
> Public Interest Advocacy Centre
> • John Lawford, Executive Director and General Counsel
>
>

Re: Rogers Outage Canada

[Victor Kuarsingh]

This is the most they can and will say.  For liabilities reasons, specifics
are likely not in the cards.  As most services ride over common service
networks, its quite possible that a network substrate failure can have a
number of upstream service impacts.  The point here is that the CEO is
directly addressing the customer base, which is needed here.

regards,

Victor K

On Mon, Jul 11, 2022 at 10:11 AM Shane Ronan  wrote:

> What in depth analysis have you seen? Seems to me, this was a failure in a
> known maintenance activity, and they simply disconnected the devices under
> maintenance from the network.
>
> Shane
>
> On Mon, Jul 11, 2022 at 5:41 AM Jon Sands  wrote:
>
>> Given the outage was so bad it was disrupting select E911 services
>> nationwide for something like 24+ hours, it's great to see such an in depth
>> analysis and plan of action to prevent such things in the future. bravo
>> rogers
>>
>> On 7/10/2022 2:55 PM, L F wrote:
>>
>> fyi - see BOLD.
>>
>> A Message from Rogers President and CEO
>>
>>
>> Dear Valued Customer,
>>
>> As you know, we experienced a service outage across the Rogers, Fido,
>> Chatr and Cityfone wireless networks on Friday.
>>
>> I am reaching out to share that our services have been restored, and our
>> networks and systems are close to fully operational. Our technical teams
>> are continuing to monitor for any remaining intermittent issues. I also
>> want to outline an action plan we are putting in place to address what
>> happened.
>>
>> I want to share what we know about what happened on Friday. We now
>> believe *we’ve narrowed the cause to a network system failure following
>> a maintenance update in our core network, which caused some of our routers
>> to malfunction. We disconnected the specific equipment and redirected
>> traffic,* which allowed our network and services to come back online
>> over time as we managed traffic volumes returning to normal levels.
>>
>>
>>
>> On Sat, Jul 9, 2022 at 9:09 PM L F  wrote:
>>
>>>
>>> Lest we ALL MOVE ON….
>>>
>>>
>>> Yes he said
>>>
>>> “RETARD” =
>>>
>>> The delay in processing the current status of a Situation…
>>>
>>>
>>> Lets move on to bigger n scarier Post mortems:
>>>
>>>
>>> Was This or Was this NOT
>>>
>>> A CYBERATTACK ???
>>>
>>> Done.
>>>
>>> Lets deal with REAL threats not PC references.
>>>
>>> Time to evaluate n re eval Our NTS!!
>>>
>>> Veni vidi vici 2022
>>>
>>>
>>>
>>>
>>> On Sat, Jul 9, 2022 at 5:01 PM Eric Kuhnke 
>>> wrote:
>>>
 Can we have a discussion with the list admins about a list member
 appending a threat of violence to their outbound emails?  Whether serious
 or not.

 Does this person need directions to some local mental healthcare
 resources?


 On Sat, 9 Jul 2022 at 08:48, Keith Medcalf  wrote:

>
> >I can't either, but the reality right now seems to be that 911 calls
> are
> >failing for anyone on a Rogers cellphone.
>
> This is par for the course.  These people chose to deal with Rogers
> despite knowing the consequences.  It is like if you bought a Rogers
> Snowblower and it did not work.  That would mean that people who bought 
> the
> Rogers Snowblower will not be using it to get rid of the snow that is
> preventing them from leaving their house.
>
> Mutatis mutandis when Rogers is down things that are Rogers dependent
> will not work.
>
> Some people are so retarded it is astonishing!
>
> --
> (CAUTION) You are advised that if you attack my person or property,
> you will be put down in accordance with the provisions of section 34 & 35
> of the Criminal Code respectively.  If you are brandishing (or in
> possession) of a weapon then lethal force will be applied to your person 
> in
> accordance with the law.  This means that your misadventures may end in
> your death.  Consider yourself cautioned and govern your actions
> appropriately.
>
> >-Original Message-
> >From: NANOG  On Behalf
> Of
> >Eric Kuhnke
> >Sent: Friday, 8 July, 2022 13:34
> >To: jim deleskie 
> >Cc: NANOG list 
> >Subject: Re: Rogers Outage Canada
> >
> >
> >I have seen anecdotal reports that the mobile network is in a half
> broken
> >state that phones remain registered to, so a 911 call will attempt and
> >then fail.
> >
> >
> >This is unlike what would happen if you had a US/Canada cellphone with
> >battery power but no SIM card in it that would search for any
> available
> >network in RF range for a 911 call if needed.
> >
> >
> >On Fri, 8 Jul 2022 at 12:31, jim deleskie  > > wrote:
> >
> >
> >   i cant see BGP taking out SS7.
> >
> >   -jim
> >
> >   On Fri, Jul 8, 2022 at 2:45 PM Snowmobile2004
> >mailto:greenjosh6...@gmail.com> > wrote:
> >
> >
> >   According to Clo

Re: Rogers Outage Canada

[Victor Kuarsingh]

We should move on and focus on constructive comments vs. kicking an
operator when they are down.

That said, demeaning comments, no matter what they are or whom they are
targeted at, is not healthy and is not helpful.

regards,

Victor K

On Sat, Jul 9, 2022 at 9:11 PM L F  wrote:

>
> Lest we ALL MOVE ON….
>
>
> Yes he said
>
> “RETARD” =
>
> The delay in processing the current status of a Situation…
>
>
> Lets move on to bigger n scarier Post mortems:
>
>
> Was This or Was this NOT
>
> A CYBERATTACK ???
>
> Done.
>
> Lets deal with REAL threats not PC references.
>
> Time to evaluate n re eval Our NTS!!
>
> Veni vidi vici 2022
>
>
>
>
> On Sat, Jul 9, 2022 at 5:01 PM Eric Kuhnke  wrote:
>
>> Can we have a discussion with the list admins about a list member
>> appending a threat of violence to their outbound emails?  Whether serious
>> or not.
>>
>> Does this person need directions to some local mental healthcare
>> resources?
>>
>>
>> On Sat, 9 Jul 2022 at 08:48, Keith Medcalf  wrote:
>>
>>>
>>> >I can't either, but the reality right now seems to be that 911 calls are
>>> >failing for anyone on a Rogers cellphone.
>>>
>>> This is par for the course.  These people chose to deal with Rogers
>>> despite knowing the consequences.  It is like if you bought a Rogers
>>> Snowblower and it did not work.  That would mean that people who bought the
>>> Rogers Snowblower will not be using it to get rid of the snow that is
>>> preventing them from leaving their house.
>>>
>>> Mutatis mutandis when Rogers is down things that are Rogers dependent
>>> will not work.
>>>
>>> Some people are so retarded it is astonishing!
>>>
>>> --
>>> (CAUTION) You are advised that if you attack my person or property, you
>>> will be put down in accordance with the provisions of section 34 & 35 of
>>> the Criminal Code respectively.  If you are brandishing (or in possession)
>>> of a weapon then lethal force will be applied to your person in accordance
>>> with the law.  This means that your misadventures may end in your death.
>>> Consider yourself cautioned and govern your actions appropriately.
>>>
>>> >-Original Message-
>>> >From: NANOG  On Behalf Of
>>> >Eric Kuhnke
>>> >Sent: Friday, 8 July, 2022 13:34
>>> >To: jim deleskie 
>>> >Cc: NANOG list 
>>> >Subject: Re: Rogers Outage Canada
>>> >
>>> >
>>> >I have seen anecdotal reports that the mobile network is in a half
>>> broken
>>> >state that phones remain registered to, so a 911 call will attempt and
>>> >then fail.
>>> >
>>> >
>>> >This is unlike what would happen if you had a US/Canada cellphone with
>>> >battery power but no SIM card in it that would search for any available
>>> >network in RF range for a 911 call if needed.
>>> >
>>> >
>>> >On Fri, 8 Jul 2022 at 12:31, jim deleskie >> > > wrote:
>>> >
>>> >
>>> >   i cant see BGP taking out SS7.
>>> >
>>> >   -jim
>>> >
>>> >   On Fri, Jul 8, 2022 at 2:45 PM Snowmobile2004
>>> >mailto:greenjosh6...@gmail.com> > wrote:
>>> >
>>> >
>>> >   According to Cloudflare Radar
>>> > ,
>>> Rogers
>>> >BGP announcements spiked massively to levels 536,777% higher than normal
>>> >(343,601 vs 64 normally) just minutes before the outage. I would not be
>>> >surprised if this happened to be the culprit.
>>> >
>>> >   Regards,
>>> >   Josh Green
>>> >
>>> >   On Fri, Jul 8, 2022 at 2:19 PM Andrew Paolucci via NANOG
>>> >mailto:nanog@nanog.org> > wrote:
>>> >
>>> >
>>> >   In the early hours of the morning around 2-3am
>>> my modem
>>> >got hit with a configuration update that caused a DHCP release that
>>> >wasn't renewed for about two hours, after rollback the connection was
>>> >fine for 3 hours before this network wide outage.
>>> >
>>> >
>>> >   Maybe a failed night time update was attempted
>>> again
>>> >during office hours, I've heard daytime guys are still WFH and night
>>> >shift is in building.
>>> >
>>> >
>>> >   I expect we'll never get a real explanation.
>>> Rogers is
>>> >notorious for withholding any type of helpful or technical information.
>>> >
>>> >
>>> >   Sent from my inoperable Rogers Mobile via
>>> emergency eSIM.
>>> >
>>> >
>>> >   Regards,
>>> >
>>> >   Andrew Paolucci
>>> >    Original Message 
>>> >   On Jul. 8, 2022, 1:48 p.m., Jay Hennigan <
>>> j...@west.net
>>> > > wrote:
>>> >
>>> >
>>> >   On 7/8/22 07:44, Robert DeVita wrote: >
>>> Does anyone
>>> >have information on a widespread Rogers outage in Canada. I > have
>>> >customers with multiple sites down. There's discussion on the Outages
>>> >mailing list. Seems widespread, affecting all services, mobile, voice,
>>> >Internet. No cause or ETR posted yet. -- Jay Hennigan - j...@

Re: IPv6 woes - RFC

[Victor Kuarsingh]

On Thu, Sep 30, 2021 at 10:01 PM Valdis Klētnieks 
wrote:

> On Wed, 29 Sep 2021 16:09:26 -0400, Victor Kuarsingh said:
>
> > - Both providers provide IPv6 and delegate a prefix to the router (let's
> > pretend the retail staff knew enough to sell this person a consumer box
> > with 2x WAN interfaces)
>

Just to make it clear, I would love it all to work really well and by
default.  But I also look at the reality and don't over estimate how
proficient consumers will be.


>
> So... do such boxes exist in any great quantity?
>

Not in great quantity.  But for the fun of it, I ran down to the local
BestBuy recently and they offered me a dual WAN router (only one type) in
stock.  So, I guess sufficient supply?


>
> Do consumers who can't add a valid number after 'IPv' accidentally
> contract for
> Internet service from two different providers often? Do they intentionally
> do
> that often?
>

Likely not accidentally, but the router they showed me (will not say what
brand on this list) showed a "WAN" and "WAN/DMZ" port, so just as clear as
any other port markings for consumer grade connections.


>
> It sounds like a sufficiently rare situation that "clueless lawyer/whatever
> hires somebody with clue for 2 hours work to configure it all" is a
> reasonable
> solution.
>

Yes, I suspect that may happen. How many clueful IPv6 folks do we suspect
service this market which are available at a cost most will be willing to
pay?

regards,

Victor K

Re: IPv6 woes - RFC

[Victor Kuarsingh]

On Wed, Sep 29, 2021 at 5:49 PM Baldur Norddahl 
wrote:

>
>
> On Wed, 29 Sept 2021 at 22:11, Victor Kuarsingh  wrote:
>
>> In the consumer world (Where a consumer has no idea who we are, what IP
>> is and the Internet is a wireless thing they attach to).
>>
>> I am only considering one router (consumer level stuff).  Here is my
>> example:
>>
>
> I am afraid you are tailor making your case. We could just as well have an
> even more clueless customer that simply buys a 4G/5G router and attaches it
> to the inside of his LAN in addition to the wifi router he got from his
> DSL/cable/xPON service. Guess what will happen? It wont work as far as IPv4
> goes but it _will_ work with IPv6.
>
> As for the tailor made case where the customer buys a device actually made
> for this, said device would also implement IPv6 for dual WAN. Plenty of
> options for how the device could do that, including the possibility of
> doing 1:1 stateless IPv6 NAT or simply presenting both prefixes to the LAN
> and source route to the correct ISP.
>

You are correct - various cases will have different results (in fact my
main concern is that with consumer gear - there is quite a bit of
variability in what we can expect).

As for my use case, you are right, it was very specific, but that was on
purpose to have a fruitful discussion (versus hand waving things).  I also
wanted to discuss the dual prefix item as well (which was being discussed).
However it is a very real example and shows up in networks (at least in
NA).  I am sure we can draw a very long table of use cases with different
results.

Don't get me wrong, I want IPv6 to work better, I spent a lot of time
implementing IPv6 in multiple networks. That said, I also don't want to
ignore real common uses cases which impact customers and need to be
resolved.

I would like to dig into your use case a bit just so I understand.  I guess
in this case - you assumed the customer would hook up the LTE/5G router
using LAN side ports (no WAN side port).  That makes sense.  I bring this
up because what I had found when looking at direct network data is that
most consumers serialize connecting second routers to each other (but
that's a single provider use case - so I digress).

In this case, when we say "it won't work".  Do we mean nothing works? or
that the effective result of having a redundant connection to two providers
wont work. I agree that only one side, for IPv4 could work as the host
would only get an address from one or the other router.  This is a great
use case for IPv6 in terms of the benefits for dual router situations.

All that said, I do personally (because of impact on call centers and
costs) differentiate outcomes where something "does not have the full
intended redundancy" (but still works and gets people to the Internet)
versus "can supply brokenness driving calls and IT support" (the latter is
more serious in my opinion).

regards,

Victor K


>
> Regards,
>
> Baldur
>
>

Re: IPv6 woes - RFC

[Victor Kuarsingh]

On Wed, Sep 29, 2021 at 4:51 PM Michael Thomas  wrote:

>
> On 9/29/21 1:09 PM, Victor Kuarsingh wrote:
>
>
>
> On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong  wrote:
>
>>
>>
>> On Sep 29, 2021, at 09:25, Victor Kuarsingh  wrote:
>>
>> 
>>
>>
>> On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG 
>> wrote:
>>
>>> Use SLAAC, allocate prefixes from both providers. If you are using
>>> multiple routers, set the priority of the preferred router to high in the
>>> RAs. If you’re using one router, set the preferred prefix as desired in the
>>> RAs.
>>>
>>> Owen
>>>
>>
>> I agree this works, but I assume that we would not consider this a
>> consumer level solution (requires an administrator to make it work).  It
>> also assumes the local network policy allows for auto-addressing vs.
>> requirement for DHCP.
>>
>>
>> It shouldn’t require an administrator if there’s just one router. If
>> there are two routers, I’d say we’re beyond the average consumer.
>>
>
> In the consumer world (Where a consumer has no idea who we are, what IP is
> and the Internet is a wireless thing they attach to).
>
> I am only considering one router (consumer level stuff).  Here is my
> example:
> - Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home and buy a
> local cable service and/or DSL service, and/or xPON service
>
> Isn't the easier (and cheaper) thing to do here is just use a VPN to get
> behind the corpro firewall? Or as is probably happening more and more there
> is no corpro network at all since everything is outsourced on the net for
> smaller companies like your law firm.
>

For shops with IT departments, sure that can make sense.  For many mom/pop
setups, maybe less likely.  The challenge for us (in this industry) is that
we need to address not just the top use cases, but the long tail as well
(especially in this new climate of more WFH).

regards,

Victor K



>
> The use cases that stuck in my mind for the justification for the need for
> routing was for things like Zigbee and other low power networks where you
> want them isolated from the chatter of the local lan. Not saying that I
> agree with the justification, but that was it iirc.
>
> Mike
>

Re: IPv6 woes - RFC

[Victor Kuarsingh]

On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong  wrote:

>
>
> On Sep 29, 2021, at 09:25, Victor Kuarsingh  wrote:
>
> 
>
>
> On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG 
> wrote:
>
>> Use SLAAC, allocate prefixes from both providers. If you are using
>> multiple routers, set the priority of the preferred router to high in the
>> RAs. If you’re using one router, set the preferred prefix as desired in the
>> RAs.
>>
>> Owen
>>
>
> I agree this works, but I assume that we would not consider this a
> consumer level solution (requires an administrator to make it work).  It
> also assumes the local network policy allows for auto-addressing vs.
> requirement for DHCP.
>
>
> It shouldn’t require an administrator if there’s just one router. If there
> are two routers, I’d say we’re beyond the average consumer.
>

In the consumer world (Where a consumer has no idea who we are, what IP is
and the Internet is a wireless thing they attach to).

I am only considering one router (consumer level stuff).  Here is my
example:
- Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home and buy a
local cable service and/or DSL service, and/or xPON service
- Both providers have IPv6 (competing in the market so don't cooperate on
how to address, manage customer homes)
- Mr/Ms/Ze Smith has no idea what IPv4 is, what IPv6 is or anything
anything else technical (typical consumer); They only knows how to walk
into a store and buy a random thing off the shelf and ask for "WiFi".
- Both providers provide IPv6 and delegate a prefix to the router (let's
pretend the retail staff knew enough to sell this person a consumer box
with 2x WAN interfaces)
- Lets also assume the cable boxes have a consumer actionable way to force
R1483 mode, and assume the DSL device can do the same (I know many
providers that don't allow this type of configuration)
- So this dual WAN (retail) device now has one Public IPv4 address per WAN
interface (assuming one or both of the services was not disallowing
bridging mode, in which case its a Private address on one or both of the
WAN interfaces)
- this dual wan device also gets a PD from both upstream providers which
delegates to the CPE

I will ignore the dual router case as that normally looks very ugly in
networks as customers typically don't hook that up correctly (normally hook
one box in behind the first, not in parallel).   Do we think this use case
just works today?  Can we say we are confident we know how this all pans
out in real production?  e.g. CPE only uses one PD? uses both?  does all
the right things to support SLAAC downstream?

I hate to say it, but for the IPv4 case, as ugly as NAT is, I know what
happens and normally the consumer has no clue what's going on and the
router just deals with it. For the IPv6 side, I am not yet confident this
is all just working yet.  I would like to be wrong.  I can say - in my
consumer mode in the US - this example above is not working by default. (I
won't out the providers of course).  I want the answer to be different, but
there is still more work to do (especially since dual provider has become
much more common due to work from home).

regards,

Victor K







>
> I have had IPv6 in my home for a long time now using multiple providers,
> but it definitely works with high touch admin.  I don't see this as a
> barrier to deploy IPv6 though (don't read that into my response).  But IPv6
> still has a few corner cases that require some TLC.
>
>
> It’s not high touch in my environment, but my environment goes way beyond
> consumer and involves ARIN assigned GUA and BGP.
>
> Not every home is the same.
>
> Owen
>
>
> regards,
>
> Victor K
>
>
>
>
>
>
>>
>>
>> On Sep 29, 2021, at 07:35, Christopher Morrow 
>> wrote:
>>
>> 
>>
>>
>> On Wed, Sep 29, 2021 at 4:39 AM  wrote:
>>
>>> Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?
>>>
>>> Im currently dual homed, having 2 uplinks, RFC1918 LAN, doing policy
>>> routing and NATing however I want..
>>>
>>>
>> why of COURSE you do source address selection!
>> so simple!
>>
>>
>>>
>>> -- Original message --
>>>
>>> From: Mark Andrews 
>>> To: b...@uu3.net
>>> Cc: nanog@nanog.org
>>> Subject: Re: IPv6 woes - RFC
>>> Date: Wed, 29 Sep 2021 00:28:40 +1000
>>>
>>>
>>>
>>> > On 28 Sep 2021, at 19:19, b...@uu3.net wrote:
>>> >
>>> > Heh, NAT is not that evil after all. Do you expect that all the home
>>> > people will get routable public IPs for all they toys inside house?
>>&g

Re: IPv6 woes - RFC

[Victor Kuarsingh]

On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG 
wrote:

> Use SLAAC, allocate prefixes from both providers. If you are using
> multiple routers, set the priority of the preferred router to high in the
> RAs. If you’re using one router, set the preferred prefix as desired in the
> RAs.
>
> Owen
>

I agree this works, but I assume that we would not consider this a consumer
level solution (requires an administrator to make it work).  It also
assumes the local network policy allows for auto-addressing vs. requirement
for DHCP.

I have had IPv6 in my home for a long time now using multiple providers,
but it definitely works with high touch admin.  I don't see this as a
barrier to deploy IPv6 though (don't read that into my response).  But IPv6
still has a few corner cases that require some TLC.

regards,

Victor K






>
>
> On Sep 29, 2021, at 07:35, Christopher Morrow 
> wrote:
>
> 
>
>
> On Wed, Sep 29, 2021 at 4:39 AM  wrote:
>
>> Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?
>>
>> Im currently dual homed, having 2 uplinks, RFC1918 LAN, doing policy
>> routing and NATing however I want..
>>
>>
> why of COURSE you do source address selection!
> so simple!
>
>
>>
>> -- Original message --
>>
>> From: Mark Andrews 
>> To: b...@uu3.net
>> Cc: nanog@nanog.org
>> Subject: Re: IPv6 woes - RFC
>> Date: Wed, 29 Sep 2021 00:28:40 +1000
>>
>>
>>
>> > On 28 Sep 2021, at 19:19, b...@uu3.net wrote:
>> >
>> > Heh, NAT is not that evil after all. Do you expect that all the home
>> > people will get routable public IPs for all they toys inside house?
>>
>> Yes! Remember routable does not mean that it is reachable from outside.
>>
>> > And if they change ISP they will get new range?
>>
>> Yes!  What do you think DHCPv6 Prefix Delegation is all about?  It
>> has only been specified for 18 years now.  The IPv6 address ranges ISP
>> get for RIRs are based on handing out multiple /64 to every customer.
>>
>> > Doesnt sounds nice to me.. But I guess I its just me
>>
>> It sounds like you need to do some reading about IPv6, then actually
>> use it.  100s of millions of home customers are get routable IPv6 prefixes
>> today around the world.  It's not scary.  Things don˙˙t blow up.
>>
>> > Yeah I am aware of putting additional aliases on loopback.
>> >
>> > No futher comment about ND and DHCP.
>> >
>> > Well, at a time when TCP/IP was invented, 32bit address space looked
>> > pretty much big... I dont blame them than they didnt predicted future..
>> > Unfortunately, cant say the same about IPv6 R&D taskforce ;)
>> >
>> > Hah, multicast... Ill skip it.
>> >
>> > Followed change to support CIDR, Internet was still small and considered
>> > R&D field...
>> >
>> > Okey, I think its no need to futher pollute NANOG list with this.
>> > I said at the begining that this is just my subjective opinion.
>> > This will not help IPv6 case at all.
>> >
>> > At least from my (2) standpoint it would be really cool that IPv6
>> > would be finally addopted.
>> >
>> > I just wanted to share my toughts about why im not big fan of IPv6.
>> > I also wanted to hear other opinions what they dislike about it, no
>> > list of how cool IPv6 is and how everyone should use it right away.
>> >
>> >
>> > -- Original message --
>> >
>> > From: Owen DeLong 
>> > To: b...@uu3.net
>> > Cc: nanog@nanog.org
>> > Subject: Re: IPv6 woes - RFC
>> > Date: Sat, 25 Sep 2021 12:01:22 -0700
>> >
>> >
>> >
>> >> On Sep 25, 2021, at 01:57 , b...@uu3.net wrote:
>> >>
>> >> Well, I think we should not compare IPX to IPv4 because those protocols
>> >> were made to handle completly different networks?
>> >>
>> >> Yeah, IPv6 is new, but its more like revolution instead of evolution.
>> >>
>> >> Well, Industry seems to addapt things quickly when they are good
>> enough.
>> >> Better things replace worse. Of course its not always the case,
>> sometimes
>> >> things are being forced here.. And thats how I feel about IPv6..
>> >
>> > Sometimes worse things replace better. NAT, for example was definitely
>> not
>> > an improvement to IPv4. It was a necessary evil intended to be a
>> temporary
>> > fix.
>> >
>> >>
>> >> IPv4 Lookback is 127.0.0.1/8
>> >> You can use bind IPs within range by applications. Handy
>> >> In IPv6 its not the case.
>> >
>> > You are free to assign any additional IPv6 addresses you like to the
>> loopback
>> > interface and then bind them to applications. Personally, I haven˙˙t
>> found a
>> > particularly good use for this, but it is possible.
>> >
>> > It does mean that instead of wasting 1/256th of the entire address space
>> > in every context on loopbacks, you have to assign what you need there,
>> > but you can easily assign a /64 prefix to a loopback interface and have
>> > applications bind within range.
>> >
>> >> IPv6 ND brings new problems that has been (painfully?) fixed in IPv4.
>> >> Tables overflows, attacks and DDoS.. Why to repeat history again?
>> >
>> > Table overflows weren˙˙t fixe

Re: IPv6 woes - RFC

[Victor Kuarsingh]

On Tue, Sep 28, 2021 at 10:25 PM Randy Bush  wrote:

> > https://datatracker.ietf.org/doc/html/rfc6092
>
> good stuff.  thanks.
>

The memories are all coming back now.  I thought this was old news.

regards,

Victor K

Re: IPv6 woes - RFC

[Victor Kuarsingh]

Owen,


On Sat, Sep 18, 2021 at 23:51 Owen DeLong  wrote:

> On Sep 18, 2021, at 12:34 , Victor Kuarsingh  wrote:
>
> On Sat, Sep 18, 2021 at 2:39 PM John Levine  wrote:
>
>> It appears that Owen DeLong via NANOG  said:
>>
>>
> Glad you noted this.  Thinking this was/is purely a hardware cycle problem
> related to normal/forced upgrade strategies.  On that point, most hardware
> I know of from 2004 in larger networks is long fully depreciated and
> sweating assets 15+ years can happen, but I don't personally think this is
> the biggest issue.
>
>
> It’s certainly not purely hardware, but it also doesn’t require solving
> the entire problem across the entire backend.
>
> What is urgently needed is to fix the customer-facing front end so that it
> speaks both protocols (or at least speaks IPv6).
>

This is a great question.  So when we approached this (going back a while
now) this is what I thought too.  But I was responsible to solve this end
to end.  So just updating front end (CPEs, network routers, DHCP,
provisioning, IP address planning, security, peering/transit, staff
training, test harnesses/plans, etc) was not sufficient to turn on IPv6.

The high cost and time challenge issues were not upgrading backend servers
to IPv6, but backend provisioning systems, tools, customer support tools,
their training, and related items.  These systems were far more complex and
costly to address (especially when considering opportunity cost).   Without
all of this in place, we could not actually deploy IPv6 for production use
(it’s not just Turing it on, its our ability to operate it down to the
person answer the phone, the technician that installs and/or fixes/replaces
items in home).

Also at that time vendor CPE hardware was not as far along on IPv6
readiness (approx mid-decade 2000s).  Getting reliable code at that time
was hard with a lot of brokenness (which also could not go into production
until it was reliable).  Perhaps this a non-issue today, but it certainly
was not a something that was “ready to go” even 10-15 years.   This (IPv6
readiness in CPE code) was also competing with other priorities often
blowing up timelines which meant it had to wait as not releasing code into
production on a strict timeline was not an option for business reasons.

All said and done, we got it completed, but it far most costly than we
first thought, and IPv4 costs did not go away after we were completed.
Sure it’s possible to reduce those costs with an aggressive program, but it
is not as simple as many think.


> As you noted John, its the plethora of software, support systems, tooling,
> and most important in many environments - legacy customer management and
> provisioning systems that can be the limiting factor.  I recall looking
> back when leading IPv6 turn-up, those were the biger problems to solve
> for.  Often such systems are extremely expensive to touch and working on
> them required prioritization against direct revenue generating projects
> (opportunity cost) .  Replacing routers was just a money problem.
>
>
> Why do those systems have to be updated in order to deliver the service to
> the customer in both protocols?
>

Addressed in above comment.

When it comes to turning on IPv6 and reducing your dependency on IPv4, your
mileage may vary (in terms of real costs, complexities and deployment).

Regards,

Victor K


> I mean sure, you’ll probably need to fix some logging databases that think
> that a customers address can be logged as a uint32_t, but that’s a
> relatively small number of systems that need to be updated in that case and
> it’s not like expanding the field to uint128_t in the database is
> incompatible with the old software during the upgrade process.
>
> I am by far not saying I agree with choices made by hold-outs, but I also
> understand this is for many, not just an engineering problem to solve.
>
>
> I agree there are some systems that may make this more complex in some
> environments, but I don’t agree that it’s
> impossible (or even particularly difficult) for a content provider to
> deliver their content on both protocols today even
> if they don’t upgrade their back-end systems.
>
> Owen
>
>

Re: IPv6 woes - RFC

[Victor Kuarsingh]

On Sat, Sep 18, 2021 at 2:39 PM John Levine  wrote:

> It appears that Owen DeLong via NANOG  said:
> >> The cost of putting flyers in the bills rounds to zero, so yes, really.
> I expect these companies all have plans
> >to support v6 eventually, someday, once they're retired and replaced all
> of the old junk that handles v6 poorly or
> >not at all, but you know about accountants and depreciation.
> >
> >Unless their infrastructure runs significantly on hardware and software
> pre-2004 (unlikely), so does the cost of
> >adding IPv6 to their content servers. Especially if they’re using a CDN
> such as Akamai.
>
> I wasn't talking about switches and routers.  I was talking about every
> single piece of software and equipment that
> they use for support and marketing and customer service and all the other
> stuff that big companies do.
>
> As I may have said once or twice, eventuallly it'll all be replaced so it
> works on IPv6 but we're not holding our breath.
>

Glad you noted this.  Thinking this was/is purely a hardware cycle problem
related to normal/forced upgrade strategies.  On that point, most hardware
I know of from 2004 in larger networks is long fully depreciated and
sweating assets 15+ years can happen, but I don't personally think this is
the biggest issue.

As you noted John, its the plethora of software, support systems, tooling,
and most important in many environments - legacy customer management and
provisioning systems that can be the limiting factor.  I recall looking
back when leading IPv6 turn-up, those were the biger problems to solve
for.  Often such systems are extremely expensive to touch and working on
them required prioritization against direct revenue generating projects
(opportunity cost) .  Replacing routers was just a money problem.

I am by far not saying I agree with choices made by hold-outs, but I also
understand this is for many, not just an engineering problem to solve.

regards,

Victor K


>
> R's,
> John
>

Re: IGP protocol

[Victor Kuarsingh]

IM,

Some good comments on this thread so far.

Having chosen between OSPF and IS-IS more then once over the past 20 years
for various networks and have chosen differently in some cases.  I have a
general preference for IS-IS in very large networks, but OSPF has performed
well for me in larger nertowrks as well.  I would say at this point, they
both can do the same basic job with a few benefits attributable to each of
them.  With OSPFv3 now more mature, I am sure there may have been a few
classic selections of IS-IS that may no longer go that way (+10 years ago,
many with OSPFv2 networks turned on IS-IS since OSPFv3 implementations were
quite new and IPv6 was staring to come online on backbones).

Anyone turning on either IGP today, the major considerations (in my mind
would be).

1. Which protocol do you have the operational staff to support? (Someone
has to fix things when broken, so what talent do you have in ops?)
2. What protocol design capabilities do you have? (Good designers can learn
either protocol, but historical experience can help in some cases)
3. Based on your vendor preference / selection, how well does each fair on
your platform of choice ? (Most major vendors do a good job on both, but
there are considerations)
5. Some people like that IS-IS is not based on IP and operates directly
over Layer-2 (some arguable benefits in security domain - but you can
secure both)
6. You running IPv4 and/or IPv6 on your underlay? (If you are running v4
only and use overlay for v4/v6 - some like the maturity of the OSPFv2
implementation)
7. Considerations for how you want your areas to run (some key differences
in how L1/L2 areas work in IS-IS along with how boundaries work vs. OSPF
areas and boundaries).
8. Route types.  In some networks, folks want to import routes from other
protocols (sometimes incoming protocols running at edges of networks etc).
If you have that, you may want to consider how you want routes to operate.

Regards,

Victor K






On Mon, Nov 12, 2018 at 2:45 PM im  wrote:

> goodmorning nanog,
>
> I heard that OSPF is only famous in asia region...
> So that, please could you explain me
>
>   1. what is your backbone's IGP protocol?
>   2. why you choose it?
>
>
> thanks,
>

Re: Death of the Internet, Film at 11

[Victor Kuarsingh]

Clinton,


On 10/23/2016 8:12 AM, clinton mielke wrote:


My question for you guys, since Im a theoretician and not a seasoned
operator: how feasible or legal is it to find telnet scanning activity or
any of these passwords in high-bandwidth netflows? If its feasible, then
this at least gets you the active scanning population of hosts, along with
the IPs of all of their victims.


If there is enough concentration of common flows from a certain set of 
IPs, it's quite possible to detect the scanning activity using sampled 
flow data if one were collecting such data.  I say sampled as 1-for-1 
flow data collection is not common.


You would not see packet content just using flow data.

regards,

Victor K

Re: Looking for information on IGP choices in dual-stack networks

[Victor Kuarsingh]

I/we (Philip and I) attempted to keep the question as generic as 
possible, allowing folks to state the IGPs they use, in whichever 
combination or in some cases (as we can see), more complex deployments.


I would agree with statements form Joel earlier with respect to cases 
where early vendor support may have influenced some network zones 
(inside a given AS) to support a different IGP (his case of OSPFv3 for 
devices which lacked IS-IS support is one I did face a few years back as 
well in the DC with respect to Load balancing  and Firewall devices).


The merger one was a new one for me, but it seems to reflect some 
peoples reality.



regards,

Victor K



On 2015-06-09 7:41 PM, Joe Abley wrote:

Hi Randy,

On Jun 9, 2015, at 18:08, Randy Bush  wrote:


Routers makes more sense to me than networks (IGP, so one network,
right?)

so you are thinking of a network where half the routers run is-is one
quarter ospf/ospfv2 and one quarter ospf/ripv3.  right.

No, not at all. I thought Victor was asking "what IGP" and "how many
routers use it in your network". I assumed he was interested in
whether the size of the network influenced the IGP choice.

Perhaps I misunderstood, because apparently I was the only one who
read it that way.


Joe

Looking for information on IGP choices in dual-stack networks

[Victor Kuarsingh]

Nanog Folks:

Philip Matthews and I are co-authors on an active draft within the IETF 
related to IPv6 routing design choices.  To ensure we are gathering 
sufficient data we are looking for an expanded set of input from 
operator forums as well (vs. just the v6ops IETF list).  The draft is 
found here -(https://tools.ietf.org/html/draft-ietf-v6ops-design-choices).


We are looking for information on the IGP combinations people are 
running in their dual-stack networks. We are gathering this information 
so we can document in our draft which IGP choices are known to work well 
(i.e., people actually run this combination in production networks 
without issues). The draft will not name names, but just discuss things 
in aggregate: for example, "there are 3 large and 2 small production 
networks that run OSPF for IPv4 and IS-IS for IPv6, thus that 
combination is judged to work well".
If you have a production dual-stack network, then we would like to know 
which IGP you use to route IPv4 and which you use to route IPv6.  We 
would also like to know roughly how many routers are running this 
combination. Feel free to share any successes or concerns with the 
combination as well.
We are looking particularly at combinations of the following IGPs:  
IS-IS, OSPFv2, OSPFv3, EIGRP.
If you run something else (RIP?) then we would also like to hear about 
this, though we will likely document these differently. [We suspect you 
run RIP/RIPng only at the edge for special situations, but feel free to 
correct us].


And if you have one of those modern networks that carries dual-stack 
customer traffic in a L3VPN or similar and thus don’t need a 
dual-stacked core, then please email us and brag ...


If you are on multiple lists at RIPE, NANOG or the IETF, we appologize 
for any redundant emails you may get (we are just attempting to reach 
the widest audience possible).


Philip Matthews
Victor Kuarsingh

Re: turning on comcast v6

[Victor Kuarsingh]

Leo,


On Mon, Dec 30, 2013 at 6:24 PM, Leo Bicknell  wrote:

>
> On Dec 30, 2013, at 2:49 PM, Lee Howard  wrote:
>
> > I'm not really an advocate for or against DHCP or RAs.  I really just
> want
> > to understand what feature is missing.
>
> I encourage you to try this simple experiment in your lab, because this
> happens all day long on corporate networks around the world, and
> illustrates the differences quite nicely.  While not a complete treatment
> of the operational differences, it's an important illustration.
>
> Configure up a simple network topology of three boxes representing a hub
> and spoke network:
>
>DHCP SVR
>   |
> --lan--r1--wan--hubrtr--wan--r2--lan
>
>
> .


>
> Here's what you will soon find:
>
> 1) The IPv6 pings on both machines cease to work.
>
> 2) The IPv4 network continues to work just fine.
>
>
>
Yes, in this very specific case, you may get this result.  However, this is
a very specific case with very specific parameters and conditions.  There
are also many cases (again specific in nature) which would cause the IPv4
connection to have problems and not the IPv6 connection.

As an example, say the failure is now over and we have running state with
r1 and r2 as two potential routers out of the LAN to a common WAN for IPv4
and IPv6 connectivity.  The DHCPv4 server provides only the address of the
r2 router (original on that LAN).  Both r1 and r2 provide RAs and the
client works over r2 for IPv6 for now.  r1 fails, the machines will lose
IPv4 connectivity but IPv6 will keep working (as the hosts will detect r1
as unreachable and then use r2).  There are a number of assumptions in this
use case - but that's the point.  One may say that without IPv4, perhaps we
have a problem anyway (since I am sure many networks will have some level
of dependance on IPv4 for a while) - but the designers of IPv6 will then
say that the IPv6 protocol needs to be free from IPv4 baggage to truly
succeed IPv4.

I am not fighting against the case of the DHCPv6 option, but I am not sure
if use cases like the one you mentioned will convince the right audiences
that the option is needed.

For reference, this concept has died on the vine before -
draft-droms-dhc-dhcpv6-default-router-00 as an example. (where technical
comments were made to diminish the technical value of using DHCPv6 as an
option to provide default gateway information).  We can also
reference draft-ietf-mif-dhcpv6-route-option from the MIF working group.

I think a new initiative to revive this concept will need to address the
[negative] points from those previous experiences and contrast them to the
operational benefits of having it available.  I am willing to help out
here, but we need some folks willing to put the use cases together which
make a strong case (oh and they will need email stamina).

regards,

Victor K




>  --
>Leo Bicknell - bickn...@ufp.org - CCIE 3440
> PGP keys at http://www.ufp.org/~bicknell/
>
>
>
>
>
>

Re: turning on comcast v6

[Victor Kuarsingh]

On Mon, Dec 30, 2013 at 6:31 PM, Leo Bicknell  wrote:

>
> On Dec 30, 2013, at 4:37 PM, Victor Kuarsingh  wrote:
>
> > On Mon, Dec 30, 2013 at 3:49 PM, Lee Howard  wrote:
> >>> The better question is are you using RIP or ICMP to set gateways in
> your
> >>> network now?
> >>
> >> I disagree that that's a better question.
> >> I'm not using RIP because my hosts don't support it (at least, not
> without
> >> additional configuration), and it would be a very unusual configuration,
> >> adding weight and complexity for no benefit.  RAs are the opposite.
> >> Not even sure how you would use ICMP to set a default gateway.  Maybe
> >> there's a field I'm unaware of.
> >>
> >
> > [VK] The RIP comparison is somewhat confusing to me.  I don't see how RIP
> > is comparable in this context (I guess technically you can pass a default
> > route in RIP, but as Lee mentions, the protocol is designed for a
> different
> > purpose and requires configuration).
>
> There was a time, I'm going to roughly guess approximately 1987-1992,
> although
> I may be off by a year or two, that you needed to have lived through for
> this
> to make sense.
>
> You see, in that time the available IGP was, well, RIP.  RIPv1.  Routers,
> at
> least ones you could buy, did not have OSPF, EIGRP, or even in many cases
> EGP/BGP.  They had RIPv1, and perhaps some bleeding edge Cisco's had IGRP.
> So almost every campus network ran RIPv1


[VK]  Leo, I understand the case you mention, but I am not sure if this is
a parallel to what the subject is on this thread.  I would think we are
talking - not about routers and servers here - but end hosts (PCs, tablets,
home gateways, smart phones, media devices etc.) which would be the
beneficiaries of the [DHCPv6] route option information.

I still don't think that RIP's prevalence in 20+ year old network
environments, and it's lack of use today, draws a comparison to the
validity of using RAs.  I get that it [RIP] may have been "default" on may
historic boxes, so had similar effect on providing a default route, but the
protocol's purpose was not intended to do that for all the hosts on a
network (also a world where not all networks were IP as well).

RA on the other had was specifically purposed to be used to provide this
kind of information to all IPv6 stacks.  So I still think we are talking
about very different environments in protocol types, purpose and mixture of
participating hosts/routers etc.

regards,

Victor K

Re: turning on comcast v6

[Victor Kuarsingh]

On Mon, Dec 30, 2013 at 3:49 PM, Lee Howard  wrote:

> I'm not really an advocate for or against DHCP or RAs.  I really just want
> to understand what feature is missing.
>
> From:  Blake Dunlap 
> Date:  Monday, December 30, 2013 3:19 PM
> To:  Ryan Harden 
> Cc:  Lee Howard , Jamie Bowden ,
> "nanog@nanog.org" 
> Subject:  Re: turning on comcast v6
>
> > The better question is are you using RIP or ICMP to set gateways in your
> > network now?
>
> I disagree that that's a better question.
> I'm not using RIP because my hosts don't support it (at least, not without
> additional configuration), and it would be a very unusual configuration,
> adding weight and complexity for no benefit.  RAs are the opposite.
> Not even sure how you would use ICMP to set a default gateway.  Maybe
> there's a field I'm unaware of.
>

[VK] The RIP comparison is somewhat confusing to me.  I don't see how RIP
is comparable in this context (I guess technically you can pass a default
route in RIP, but as Lee mentions, the protocol is designed for a different
purpose and requires configuration).

I guess the ICMP reference fair as Neighbor Discovery is built on ICMP
(which is a good thing in my opinion).  Perhaps the reference here was to
people not using RFC1256 in their networks?



>
> >
> >
> > If you don't use those now, why is RA a better solution in ipv6?
>
> It's built into the fundamentals of IPv6, using the Neighbor Discovery
> Protocol.  It's supported in every stack.  It's the default mode of
> operation.  To turn it off, you have to disable part, but not all, of NDP.
> (Do you also turn off RSs on all hosts?)
>
>
[VK] Although I think there may be a valid case presented for an Option, I
agree with Lee with the point that Neighbor Discovery is already built-in
so it has operational benefits in that respect.  There are many IPv6
deployments out there today in both ISPs and Enterprises, where ND/RAs are
being used - this may or may not make RAs "better" then a potential DHCPv6
router option, but we know it (RA method) works in real networks using IPv6.

As for a DHCPv6 router option case being made, if there a good reason and
technical merit, that should be made to the DHC WG, or perhaps even made at
a v6ops ops meeting and the advocate should make note of points made in
draft-ietf-dhc-option-guidelines.
 Changes/updates to DHCPv6 have been made (as with RFC7083) when the
problem can be stated with technical merit and people are willing to work
on it.

regards,

Victor K

Re: DOCSIS 3.0 and Multicast

[Victor Kuarsingh]

Phil,

Been watching this conversation and had a few comments.

First, one of the concerns is exposure to wire monitoring on the HFC
(Hybrid-Fiber Coax) plant while using DOCSIS, then I think folks should be
aware that there is encryption applied to the traffic between the CMTS and
Cable Modem (CM).  This was traditionally BPI (Baseline Privacy Inspection)
and DOCSIS 3.0 supports SEC (which then allows use of AES).  I may have
missed the point along this email train, but folks may not be aware that
putting an RF capturing device on the plant, or sitting behind a CM on the
does not gain you gratuitous access to neighbouring people's data.  So if
application/network flows are also encrypted, you would not necessarily be
able to know who it's for as all payload traffic should already be
encrypted on the [DOCSIS] wire.  This however does not change eavesdropping
on the outside of the DOCSIS plan (after CM, or before CMTS).

If one did come up with a way of sending normal traffic over a DOCSIS
Multicast pipe, then there are a number of resource issues which need to be
considered (as they have operator and vendor impact).  Multicast is managed
very differently (signalling and payload) in DOCSIS vs. Unicast traffic,
and therefore resources will be an issue (i.e. IDs used to direct traffic
for Unicast are not the same as those used for Multicast).  To add, forcing
a bunch of (or all) traffic down a Multicast pipe would impact an
operator's ability to managed QoS for customers (which is already complex
enough in the DOCSIS world) and may impact CM operation (which will be
keeping track what multicast groups/packets will be forwarded for a given
service endpoint).

regards,

Victor K



On Fri, Nov 29, 2013 at 1:47 PM, Phil Karn  wrote:

> On 11/29/2013 10:03 AM, Frank Bulk wrote:
>
> > It looks like Cisco is doing something in the IP Video over DOCSIS area,
> and
> > so if you're serious about this, you could reach out to them.
>
> It's not video over IP multicast that interests me so much as the
> opportunity to thwart NSA-style bulk traffic analysis by multicasting
> unicast messages with encrypted destination addresses so an eavesdropper
> can't tell who it's for.
>
>
>
>

Re: ISIS and OSPF together

[Victor Kuarsingh]

Glen,

Yes, if you are referring to RFC5838 like functionality in OSPFv3 (AF
support) that is correct.  I personally don't have experience with that mode
of operation (as the networks I had experience with went dual stack a while
back).

I guess someone looking to dual stack now may want to consider that option.

I am personally biased towards IS-IS when looking to do both, but to each
their own.

To further my early points (not saying it's a good option, but adding some
context).  The rationale for keeping OSPFv2 was due to legacy tools and
operational procedures.  Adding a second IGP (years ago) for IPv6 was
considered (to some) a way of not specifically impacting the "bread and
butter" IPv4 service while turning up IPv6.

I guess all of that reasoning has likely changed for new IPv6 turn-ups as
there is much more operational experience with running multiple AFs now.

I should have highlighted the context before ­ sorry.

Regards,

Victor K

From:  Glen Kent 
Date:  Mon, 13 May 2013 00:13:38 +0530
To:  Victor Kuarsingh 
Cc:  "nanog@nanog.org" 
Subject:  Re: ISIS and OSPF together

Victor,

Folks could, at least theoretically, use ISIS or OSPF multi instance/multi
topology extensions to support IPv4 and IPv6 topologies. This way they would
only need to run a single protocol and thereby requiring expertise in
handling only one protocol.

With whatever i remember, OSPFv3 can be used to support IPv4 as well - so
folks could also use OSPFv3 when they want to support both IPv4 and IPv6.

Glen

On Sun, May 12, 2013 at 6:17 PM, Victor Kuarsingh  wrote:
> Glen,
> 
> One transition scenario you noted below is often a use case.  I have seen
> networks move from OSPF to IS-IS (more cases then the reverse).
> 
> In those cases, the overlap period may not be very short (years vs.
> weeks/months).
> 
> I have also seen some use one protocol (which I think was mentioned in
> another response) used for IPv4 and another used for IPv6.  The cases I am
> familiar, tended to be IPv6 with IS-IS and IPv4 with OSPFv2.
> I guess the reasoning here was that if you are running dual stack, with
> OSPF you will need to run two protocols anyway, so running OSPFv2(IPv3)
> and OSPFv3(IPv6) may not be that different then running OSPFv2(IPv4) with
> IS-IS(IPv6).  This dual stack option has run longer or is semi-permanent
> at times.
> 
> A sub-case to the above may also be that one (operator) may want to
> leverage some of capabilities of IS-IS and may not be willing to get off
> OSPF for some reason.  The Multi-topology option in IS-IS may be quite
> useful if you have some functions which are non-congruent in your network
> and you want to maintain topology variations (multicast being one, or
> in-band management which I believe was alluded to in your OOB use case)
> 
> Regards,
> 
> Victor K
> 
> 
> 
> On 2013-05-12 4:41 AM, "Glen Kent"  wrote:
> 
>> >Hi,
>> >
>> >I would like to understand the scenarios wherein the service
>> >provider/network admin might run both ISIS and OSPF together inside their
>> >network. Is this something that really happens out there?
>> >
>> >One scenario that i can think of when somebody might run the 2 protocols
>> >ISIS and OSPF together for a brief period is when the admin is migrating
>> >from one IGP to the other. This, i understand never happens in steady
>> >state. The only time this can happen is if an AS gets merged into another
>> >AS (due to mergers and acquisitions) and the two ASes happen to run ISIS
>> >and OSPF respectively. In such instances, there is a brief period when two
>> >protocols might run together before one gets turned off and there is only
>> >one left.
>> >
>> >The other instance would be when say OSPF is used to manage the OOB
>> >network
>> >and the ISIS is used for network reachability.
>> >
>> >Is there any other scenario?
>> >
>> >Glen
> 
> 

Re: ISIS and OSPF together

[Victor Kuarsingh]

Glen,

One transition scenario you noted below is often a use case.  I have seen
networks move from OSPF to IS-IS (more cases then the reverse).

In those cases, the overlap period may not be very short (years vs.
weeks/months).

I have also seen some use one protocol (which I think was mentioned in
another response) used for IPv4 and another used for IPv6.  The cases I am
familiar, tended to be IPv6 with IS-IS and IPv4 with OSPFv2.
I guess the reasoning here was that if you are running dual stack, with
OSPF you will need to run two protocols anyway, so running OSPFv2(IPv3)
and OSPFv3(IPv6) may not be that different then running OSPFv2(IPv4) with
IS-IS(IPv6).  This dual stack option has run longer or is semi-permanent
at times.

A sub-case to the above may also be that one (operator) may want to
leverage some of capabilities of IS-IS and may not be willing to get off
OSPF for some reason.  The Multi-topology option in IS-IS may be quite
useful if you have some functions which are non-congruent in your network
and you want to maintain topology variations (multicast being one, or
in-band management which I believe was alluded to in your OOB use case)

Regards,

Victor K

 

On 2013-05-12 4:41 AM, "Glen Kent"  wrote:

>Hi,
>
>I would like to understand the scenarios wherein the service
>provider/network admin might run both ISIS and OSPF together inside their
>network. Is this something that really happens out there?
>
>One scenario that i can think of when somebody might run the 2 protocols
>ISIS and OSPF together for a brief period is when the admin is migrating
>from one IGP to the other. This, i understand never happens in steady
>state. The only time this can happen is if an AS gets merged into another
>AS (due to mergers and acquisitions) and the two ASes happen to run ISIS
>and OSPF respectively. In such instances, there is a brief period when two
>protocols might run together before one gets turned off and there is only
>one left.
>
>The other instance would be when say OSPF is used to manage the OOB
>network
>and the ISIS is used for network reachability.
>
>Is there any other scenario?
>
>Glen

Operational Experience with SSR

[Victor Kuarsingh]

All,

I was looking for anyone who has operational experience with the SSR
platform used as a SGW and/or PGW function in mobile environment.

Please contact me off-list.

Thanks,

Victor Kuarsingh

Re: Does anyone use anycast DHCP service?

[Victor Kuarsingh]

Sent from my iPad

On 2012-08-13, at 12:18 PM, sth...@nethelp.no wrote:

>> I think it would be far more reliable to simply have two independent
>> DHCP servers with mutually exclusive address ranges, and have one
>> system be secondary and "delay" its responses by 2s so it always
>> "loses" when the primary is up and running well.
>> 
>> Yes, you lose the ability for clients to get the same IP during a
>> lease refresh if the primary is down, but that is a small price to pay
>> for simplicity and robustness.
> 
> That depends on your scenario. In some situations it is important to
> get the same IP. In other situations, using potentially double the
> address space is unacceptable.

As some have noted, your environment may dictate which is better (HA with 
software considerations, or retention of IP lease information).

Example:

In an ISP environment, I would suggest that you consider prefix delegation for 
IPv6 (--assuming you plan on IPv6 at some point ).

For traditional IPv4 networks (ISP), changing the WAN side IP address occurs 
often enough that it's annoying, but tolerable.  When we consider IPv6, 
changing the WAN side IP is also reasonable (IA_NA).  But if you plan on 
supplying the home network a prefix delegation (IA_PD), you get into some 
problems if you wind up renumbering the home network.

Not sure if this example fits your profile, but at this point, I would not 
consider a deployment of any major system without considerations of IPv6.

Regards,

Victor Kuarsingh

> 

Re: IPv6 prefixes longer then /64: are they possible in DOCSIS networks?

[Victor Kuarsingh]

Dmitry et al,

I found Jeff's following comments to be quite insightful for general
practices.

http://www.networkcomputing.com/ipv6-tech-center/231600717

http://www.networkcomputing.com/ipv6-tech-center/231700160

As for using 127s on P2P links

He discussed reasoning behind using /64s, concerns related to "waste", ND
exploits and
other points as noted in RFC6164. - directed

Regards,

Victor K

On 11-11-29 7:58 AM, "Dmitry Cherkasov"  wrote:

>Thanks to everybody participating in the discussion.
>I try to summarize.
>
>1) There is no any obvious benefit of using longer prefixes then /64
>in DOCSIS networks yet there are no definite objections to use them
>except that it violates best practices and may lead to some problems
>in the future
>
>2) DHCPv6 server can use any algorithm to generate interface ID part
>of the address, and EUI-64 may be just one of them that can be useful
>for keeping correspondence between MAC and IPv6 addresses. Yet if we
>use EUI-64 we definitely need to use /64 prefix
>
>3) Using /64 networks possesses potential security threat related to
>neighbor tables overflow. This is wide IPv6 problem and not related to
>DOCSIS only
>
>There were also notes about address usage on link networks. Though
>this was out of the scope of original question it is agreed that using
>/64 is not reasonable here. BTW, RFC6164 (Using 127-Bit IPv6 Prefixes
>on Inter-Router Links) can be mentioned here.
>
>
>Dmitry Cherkasov
>
>
>
>2011/11/29 Dmitry Cherkasov :
>> Tore,
>>
>> To comply with this policy we delegate at least /64 to end-users
>> gateways. But this policy does not cover the network between WAN
>> interfaces of CPE and ISP access gateway.
>>
>> Dmitry Cherkasov
>>
>>
>>
>> 2011/11/29 Tore Anderson :
>>> * Dmitry Cherkasov
>>>
 I am determining technical requirements to IPv6 provisioning system
 for DOCSIS networks and I am deciding if it is worth to restrict user
 to use not less then /64 networks on cable interface. It is obvious
 that no true economy of IP addresses can be achieved with increasing
 prefix length above 64 bits.
>>>
>>> I am not familiar with DOCSIS networks, but I thought I'd note that in
>>> order to comply with the RIPE policies, you must assign at least a /64
>>> or shorter to each end user:
>>>
>>> http://www.ripe.net/ripe/docs/ripe-523#assignment_size
>>>
>>> --
>>> Tore Anderson
>>> Redpill Linpro AS - http://www.redpill-linpro.com
>

Re: IPv6 day fun is beginning!

[Victor Kuarsingh]

Sent from my iPad

On 2011-06-08, at 5:09 AM, Joel Jaeggli  wrote:

> 
> On Jun 7, 2011, at 5:32 PM, Jay Ashworth wrote:
> 
>> - Original Message -
>>> From: "Matt Ryanczak" 
>> 
>>> Indeed. Verizon LTE is v6 enabled but the user-agent on my phone
>>> denies me an IPv6 experience.
>> 
>> I thought I'd heard that LTE transport was *IPv6 only*...
> 
> you may have but it's wrong.  lte supports ipv4 ipv6 and dual stack contexts.
> 

Correct.  The bearer service (connection perceived by user) can be IPv4-only, 
IPv6-only or dual stack for LTE (more correctly - the Evolved Packet System).

The actual transport (mobile nodes talking to each other conducting signaling 
and tunneling customer traffic) can be IPv4 and/or IPv6.

Regards,

Victor K



>> Cheers,
>> -- jra
>> -- 
>> Jay R. Ashworth  Baylink   
>> j...@baylink.com
>> Designer The Things I Think   RFC 
>> 2100
>> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover 
>> DII
>> St Petersburg FL USA  http://photo.imageinc.us +1 727 647 
>> 1274
>> 
> 
>