Re: DoD IP Space

[Mark Tinka]

On 2/12/21 21:56, scott wrote:




100% agreed!  Been whining about that here many times.  I have been 
trying to get IPv6 going for a long time, but the above stopped my 
plans.  One thing I mentioned recently, though, is we just got a 
$BIGCUSTOMER and their requirement was we do IPv6.  So keep your IPv6 
deployment plans ready.  In my case they said a 'we need it right now' 
kind of thing.  That could happen to anyone here.


How about just doing it and then asking for forgiveness later :-)?

That's what I did in 2005, but fair point, the network was only 2 
routers big and in just one city :-).


Mark.

Fwd: IPv6 addressing: Gaps? (draft-gont-v6ops-ipv6-addressing-considerations)

[Fernando Gont]

Folks,

FYI. The intent is to discuss this on the IETF v6ops wg list 
(https://www.ietf.org/mailman/listinfo/v6ops).


But comments will be appreciated, regardless of the specific channel 
(whether on this list, off-list, etc.)


Thanks!

Regards,
Fernando




 Forwarded Message 
Subject: IPv6 addressing: Gaps? 
(draft-gont-v6ops-ipv6-addressing-considerations)

Date: Fri, 12 Feb 2021 18:50:48 -0300
From: Fernando Gont 
To: IPv6 Operations 

Folks,

In the aforementioned document 
(https://tools.ietf.org/html/draft-gont-v6ops-ipv6-addressing-considerations), 
we have tried to do at least three things:


1) Look at what we have and try to discuss things from an architectural
   perspective

2) Analyze the implications of #1 (whether operations, security,
   privacy, etc.)

3) Find missing gaps that currently prevent us from fully leveraging
   IPv6 addressing.


Part of what we've found as doing #3 above is that:

  * There are shortcomings associated with the current APIs that prevent
better usage of IPv6 addresses

  * Multi-router/multi-prefix routing seems to be broken.
RFC8028 would be a fundamental starting point in the right
direction... but I believe there's more to do in this area.


In that light, we'd like to hear further comments on our document. And, 
in particular, we're interested to hear if :


  * there are any operational implications of IPv6 addressing that we
have missed, or,

  * there's anything related to IPv6 addressing that you consider to
be currently broken or problematic, that is missing in our I-D.


Thoughts on the current contents of the I-D are, of course, also very 
welcome!


Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Re: DoD IP Space

[scott]

--- sa...@cluecentral.net wrote:
From: Sabri Berisha 

The true enemy here is mid-level management that refuses to prioritize 
deployment of IPv6.


What we should be discussing is how best to approach that problem. It's 
where ops and corporate politics overlap.

--


100% agreed!  Been whining about that here many times.  I have been 
trying to get IPv6 going for a long time, but the above stopped my 
plans.  One thing I mentioned recently, though, is we just got a 
$BIGCUSTOMER and their requirement was we do IPv6.  So keep your IPv6 
deployment plans ready.  In my case they said a 'we need it right now' 
kind of thing.  That could happen to anyone here.


scott

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 13 Feb, 2021

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  845861
Prefixes after maximum aggregation (per Origin AS):  322196
Deaggregation factor:  2.63
Unique aggregates announced (without unneeded subnets):  402923
Total ASes present in the Internet Routing Table: 70526
Prefixes per ASN: 11.99
Origin-only ASes present in the Internet Routing Table:   60682
Origin ASes announcing only one prefix:   25080
Transit ASes present in the Internet Routing Table:9844
Transit-only ASes present in the Internet Routing Table:295
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  62
Max AS path prepend of ASN (266299)  59
Prefixes from unregistered ASNs in the Routing Table:   927
Number of instances of unregistered ASNs:   933
Number of 32-bit ASNs allocated by the RIRs:  35042
Number of 32-bit ASNs visible in the Routing Table:   29074
Prefixes from 32-bit ASNs in the Routing Table:  135830
Number of bogon 32-bit ASNs visible in the Routing Table:18
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:560
Number of addresses announced to Internet:   2910555264
Equivalent to 173 /8s, 123 /16s and 140 /24s
Percentage of available address space announced:   78.6
Percentage of allocated address space announced:   78.6
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  288838

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   221583
Total APNIC prefixes after maximum aggregation:   65428
APNIC Deaggregation factor:3.39
Prefixes being announced from the APNIC address blocks:  217412
Unique aggregates announced from the APNIC address blocks:88209
APNIC Region origin ASes present in the Internet Routing Table:   11268
APNIC Prefixes per ASN:   19.29
APNIC Region origin ASes announcing only one prefix:   3225
APNIC Region transit ASes present in the Internet Routing Table:   1595
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 30
Number of APNIC region 32-bit ASNs visible in the Routing Table:   6419
Number of APNIC addresses announced to Internet:  770448384
Equivalent to 45 /8s, 236 /16s and 28 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-143673
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:243710
Total ARIN prefixes after maximum aggregation:   112158
ARIN Deaggregation factor: 2.17
Prefixes being announced from the ARIN address blocks:   244226
Unique aggregates announced from the ARIN address blocks:116434
ARIN Region origin ASes present in the Internet Routing Table:18727
ARIN Prefixes per ASN:13.04
ARIN 

Re: DoD IP Space

[Christopher Morrow]

On Fri, Feb 12, 2021 at 11:30 AM Tom Beecher  wrote:
>>
>> For most networks there is almost no pain in enabling IPv6.
>
>
> A startup vendor, formed by long time industry veterans, released brand new 
> products inside of the last 8 years that did not yet have IPv6 support 
> because their software, also created by them from scratch, did not yet 
> support it. It does now, but one could argue that it's mind boggling this 
> happened in the first place.
>

this happens, a lot :(

> When experienced industry individuals decide that V6 is second class enough 
> to chop the feature just to get the product out the door, and bolt it on to 
> code later (because THAT always works out well :) ), it really makes you 
> wonder how many more generations of engineers will be having these same 
> conversations.
>
> The money always talks. As long as solutions exist to massage V4 scarcity , 
> and those solutions remain cheaper, they will generally win.
>

the problem (one problem?) in the networking space is that:
  "Today's network works, why should I add risk / config-pain /
customer-problems / uncertainty when there's no driving reason to do
same?"

This is almost certainly why some residential providers still don't
offer v6 (verizon) on their residential link service.
-chris

Re: DoD IP Space

[Tom Beecher]

>
> For most networks there is almost no pain in enabling IPv6.
>

A startup vendor, formed by long time industry veterans, released brand new
products inside of the last 8 years that did not yet have IPv6 support
because their software, also created by them from scratch, did not yet
support it. It does now, but one could argue that it's mind boggling this
happened in the first place.

When experienced industry individuals decide that V6 is second class enough
to chop the feature just to get the product out the door, and bolt it on to
code later (because THAT always works out well :) ), it really makes you
wonder how many more generations of engineers will be having these same
conversations.

The money always talks. As long as solutions exist to massage V4 scarcity ,
and those solutions remain cheaper, they will generally win.

On Thu, Feb 11, 2021 at 5:07 PM Mark Andrews  wrote:

>
>
> > On 12 Feb 2021, at 08:11, Jim Shankland  wrote:
> >
> > On 2/11/21 6:29 AM, Owen DeLong wrote:
> >>
> >>> On Feb 11, 2021, at 05:55 , Izaac  wrote:
> >>>
> >>> On Wed, Feb 10, 2021 at 04:04:43AM -0800, Owen DeLong wrote:
>  without creating partitioned networks.
> >>> Ridiculous.  Why would you establish such a criteria?  The defining
> >>> characteristic of rfc1918 networks is that they are partitioned.
> >>>
> >>> The ability to recognize and exploit partitions within a network,
> >>> natural or otherwise, is the measure of competence in a network
> >>> engineer.
> >>>
> >>> Stop making excuses.
> >> Ridiculous… TCP/IP was designed to be a peer to peer system where each
> endpoint was uniquely
> >> addressable whether reachable by policy or not.
> >>
> >> IPv6 restores that ability and RFC-1918 is a bandaid for an obsolete
> protocol.
> >>
> >> Stop making excuses and let’s fix the network.
> >>
> >> Owen
> >
> > TCP/IP wasn't designed; it evolved (OK, a slight exaggeration). The
> ISO-OSI protocol stack was designed. Many years ago, I taught a course on
> TCP/IP networking. The course was written by someone else, I was just being
> paid to present/teach it. Anyway, I vividly remember a slide with bullet
> points explaining why TCP/IP was a transitional technology, and would be
> rapidly phased out, replaced by the "standard", intelligently designed
> ISO-OSI stack. By the time I taught the course, I had to tell the class
> that every single statement on that slide was incorrect. In the end,
> evolution beat out intelligent design, by a country mile.
> >
> > It was probably a couple of years later -- the year definitely started
> with a 1 -- that I first heard that IPv4 was being phased out, to be
> replaced over the next couple of years by IPv6. We've been hearing it ever
> since.
> >
> > That doesn't mean that we'll be living with IPv4 forever. A peer to peer
> system where each endpoint is uniquely addressable is desirable. But in a
> world of virtual machines, load balancers, etc., the binding of an IP
> address to a particular, physical piece of hardware has long since become
> tenuous. IPv4 is evolving into a 48-bit address space for endpoints (32-bit
> host + 16-bit port). That development has extended IPv4's useful life by
> many years.
> >
> > There is pain associated with continuing to make IPv4 work. And there is
> pain associated with transitioning to IPv6. IPv6 will be adopted when the
> pain of the former path is much larger than the pain of the latter path.
> Saying "RFC-1918 is a bandaid for an obsolete protocol" is using a
> normative, rather than empirical, definition of "obsolete". In the
> empirical sense, things are obsolete when people stop using them. Tine will
> tell when that happens.
> >
> > Jim Shankland
>
> For most networks there is almost no pain in enabling IPv6. Its
> reconfigure the routers to announce IPv6 prefixes and you are done.  We are
> 20+ years into IPv6 deployment.  Almost everything you buy today works with
> IPv6.  Even the crappy $50 home router does IPv6.  100s of millions of
> household networks have had IPv6 enabled without the owners of those
> networks needing to anything other than perhaps swap out a IPv4-only router
> to one that supports IPv6.  Hell lots of those home networks are behind
> IPv6-only uplinks with the CPE router translating the legacy IPv4 to IPv6
> for transport over the IPv6-only uplink.  The same happens with mobile
> phones these days.  If you have a phone that was purchased in the last 10
> years, give or take, you will most probably be talking to the world over a
> IPv6-only link.  Even Telstra here in Australia is transition their network
> to IPv6-only, the network in South Australia is IPv6-only with the other
> states to come.  Optus here has been shipping IPv6 capable routers for the
> last several years with every new install / replacement.  Optus haven’t yet
> enabled IPv6 to the home but the installed base is becoming IPv6 capable.
>
> The harder part is making sure every piece of kit works with IPv6 when you
> want to turn off IPv4 

Anyone with experience working the Oracle Cloud and IPSec connections?

[Joseph Jenkins]

We are in the process of setting up connectivity to the Oracle Cloud over
ipsec connections. I have it setup with 3 /16 subnets to route back to our
on premise network. The tunnel comes up when interesting traffic comes from
one of the subnets, however when traffic is generated from another subnet
the first subnet stops getting return traffic from OCI. Anyone with any
experience that can shed some light on this?

Re: DoD IP Space

[Owen DeLong]

Eric, I’d argue that does fall within the definition of incompetence called out 
by Izaac.

I’m talking about how you run out of RFC-1918 space (if you choose to use it in 
the first place) without incompetence.

Owen


> On Feb 11, 2021, at 09:15 , Eric Kuhnke  wrote:
> 
> You don't, you wastefully assign a /24 to every unique thing that you think 
> needs an internal management IP block (even if there's 5 things that answer 
> pings there), and decide it's too much work to renumber things. Easy for a 
> big ISP that's also acquired many small/mid-sized ISPs to run out of v4 
> private IP space that way.
> 
> 
> 
> On Wed, Feb 10, 2021 at 4:05 AM Owen DeLong  > wrote:
> Please explain to me how you uniquely number 40M endpoints with RFC-1918 
> without running out of
> addresses and without creating partitioned networks.
> 
> If you can’t, then I’m not the one making excuses.
> 
> Owen
> 
> 
> > On Feb 9, 2021, at 15:44 , Izaac mailto:iz...@setec.org>> 
> > wrote:
> > 
> > On Fri, Feb 05, 2021 at 02:36:57PM -0800, Owen DeLong wrote:
> >> it is definitely possible to run out of RFC-1918 space with scale and no 
> >> incompetence.
> > 
> > No, it isn't.  It's the year 2021.  Stop making excuses.
> > 
> > -- 
> > . ___ ___  .   .  ___
> > .  \/  |\  |\ \
> > .  _\_ /__ |-\ |-\ \__
>