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

[Randy Bush]

> https://datatracker.ietf.org/doc/html/rfc6092

good stuff.  thanks.

Re: IPv6 woes - RFC

[Mark Andrews]

> On 29 Sep 2021, at 05:02, Randy Bush  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?
> 
> in ipv6 they can.  and it can have consequences, see
> 
>NATting Else Matters: Evaluating IPv6 Access Control Policies in
>Residential Networks; 
>Karl Olson, Jack Wampler, Fan Shen, and Nolen Scaife
> 
>https://link.springer.com/content/pdf/10.1007%2F978-3-030-72582-2_22.pdf
> 
> the ietf did not give guidance to cpe vendors to protect toys inside
> your LAN

Really?

RFC6092 January 2011

Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for
Providing Residential IPv6 Internet Service

https://datatracker.ietf.org/doc/html/rfc6092

CableLabs has similar requirements.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: 100GbE beyond 40km

[Brandon Martin]

On 9/27/21 1:47 PM, Brandon Butterworth wrote:

You're looking for SOA at 1300nm, like
https://www.fs.com/uk/products/69350.html


Getting much more power out of a SOA than a -ZR QSFP28 is pretty hard, 
though they could be used for non-OEO re-generation in the middle if 
practical in your topology.


There does also exist a PDFA.  Same concept, different dopant in the 
fiber.  They are...expensive.  However, you can get a crazy amount of 
power out of them, and they're available with a lower noise floor than 
SOAs seem to be, as well.  If you really want to make that 80-100km link 
at 1310nm and without going coherent, they are a potential option.  When 
I inquired with a manufacturer/rep (what appears to be the only one in 
the world), it was almost as expensive as a coherent transponder on both 
ends.


--
Brandon Martin

Re: uPRF strict more

[Amir Herzberg]

Randy, great question. I'm teaching that it's very rarely, if ever,
used (due to high potential for benign loss); it's always great to be
either confirmed or corrected...

So if anyone replies just to Randy - pls cc me too (or, Randy, if you could
sum up and send to list or me - thanks!)

Amir
-- 
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures:
 https://sites.google.com/site/amirherzberg/applied-crypto-textbook





On Tue, Sep 28, 2021 at 8:50 PM Randy Bush  wrote:

> do folk use uPRF strict mode?  i always worried about the multi-homed
> customer sending packets out the other way which loop back to me;  see
> RFC 8704 §2.2
>
> do vendors implement the complexity of 8704; and, if so, do operators
> use it?
>
> clue bat please
>
> randy
>

uPRF strict more

[Randy Bush]

do folk use uPRF strict mode?  i always worried about the multi-homed
customer sending packets out the other way which loop back to me;  see
RFC 8704 §2.2

do vendors implement the complexity of 8704; and, if so, do operators
use it?

clue bat please

randy

Robocall Mitigation Database Call Blocking Deadline Is Today

[Sean Donelan]

According to the FCC, 4,798 companies had filed in the Robocall Mitigation 
Database with many hundreds of carriers, including all of the largest 
phone carriers, certifying to implementation of STIR/SHAKEN standards on 
their IP networks.


Beginning today, if a voice service provider’s certification and other 
required information does not appear in the FCC’s Robocall Mitigation 
Database, intermediate providers and voice service providers will be 
prohibited from directly accepting that provider’s traffic.


Note the word "directly."  Guess what's going to happen?

https://www.fcc.gov/document/fcc-robocall-mitigation-database-call-blocking-deadline-today

Re: IPv6 woes - RFC

[Randy Bush]

>> the ietf did not give guidance to cpe vendors to protect toys inside
>> your LAN
> guidance aside... 'Time To Market' (or "Minimum Viable Product - MVP!) is
> likely to impact all of our security 'requirements'. :(

that point was made in the paper i cited

> I also thought 'homenet' (https://datatracker.ietf.org/wg/homenet) was
> supposed to have provided the guidance you seek here?

got a cite for the guidance?

randy

Re: IPv6 woes - RFC

[Michael Thomas]

On 9/28/21 1:06 PM, Christopher Morrow wrote:



On Tue, Sep 28, 2021 at 3:02 PM Randy Bush > 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?

in ipv6 they can.  and it can have consequences, see

    NATting Else Matters: Evaluating IPv6 Access Control Policies in
    Residential Networks;
    Karl Olson, Jack Wampler, Fan Shen, and Nolen Scaife

https://link.springer.com/content/pdf/10.1007%2F978-3-030-72582-2_22.pdf


the ietf did not give guidance to cpe vendors to protect toys inside
your LAN


guidance aside... 'Time To Market' (or "Minimum Viable Product - MVP!) 
is likely to impact all of our security 'requirements'. :(
I also thought 'homenet' (https://datatracker.ietf.org/wg/homenet 
) was supposed to have 
provided the

guidance you seek here?



What I wonder is which string the IETF has to push on to get CPE vendors 
to... anything.


Anecdotally, I've seen firewall controls on all of the CPE I've had and 
no IPv6 (at least commercially).


Mike

Re: IPv6 woes - RFC

[Christopher Morrow]

On Tue, Sep 28, 2021 at 3:02 PM Randy Bush  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?
>
> in ipv6 they can.  and it can have consequences, see
>
> NATting Else Matters: Evaluating IPv6 Access Control Policies in
> Residential Networks;
> Karl Olson, Jack Wampler, Fan Shen, and Nolen Scaife
>
>
> https://link.springer.com/content/pdf/10.1007%2F978-3-030-72582-2_22.pdf
>
> the ietf did not give guidance to cpe vendors to protect toys inside
> your LAN
>
>
guidance aside... 'Time To Market' (or "Minimum Viable Product - MVP!) is
likely to impact all of our security 'requirements'. :(
I also thought 'homenet' (https://datatracker.ietf.org/wg/homenet) was
supposed to have provided the
guidance you seek here?

Re: IPv6 woes - RFC

[Randy Bush]

> 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?

in ipv6 they can.  and it can have consequences, see

NATting Else Matters: Evaluating IPv6 Access Control Policies in
Residential Networks; 
Karl Olson, Jack Wampler, Fan Shen, and Nolen Scaife

https://link.springer.com/content/pdf/10.1007%2F978-3-030-72582-2_22.pdf

the ietf did not give guidance to cpe vendors to protect toys inside
your LAN

randy

What happens when you don't validate/scrub data on input from whois

[Eric Kuhnke]

https://research.securitum.com/fail2ban-remote-code-execution/

What happens if you put the following in your whois entry:

drop table prefixes;

Or anything similar...

https://xkcd.com/327/

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 28, 2021, at 08:13 , Masataka Ohta  
> wrote:
> 
> Mark Andrews 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.
> 
> Do you mean, because of hole punching, "not routable" does not mean
> that it is "not reachable from outside"?
> 
>>> And if they change ISP they will get new range?
>> Yes!
> 
> The problem is that IPv6 was promised to perform *AUTOMATIC*
> *RENUMBERING*, with which, even if address ranges change, all
> the configuration information, including those for DNS glues,
> can be automatically updated.

Sure it can… That’s just software.

> With careful design by real experts, it is possible to design
> such a protocol even with IPv4 but IPv6 "committee" naturally
> abandoned to do so with IPv6.

What’s missing? We already have DDNS and DHCP is already capable of 
doing what’s needed to update the DNS server there.

If you don’t like DDNS, then there are relatively simple ways to script DNS 
updates for prefix changes as well.

Owen

Re: IPv6 woes - RFC

[Owen DeLong via NANOG]

> On Sep 28, 2021, at 02: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?

NAT is absolutely that evil after all. The presence of NAT has basically
prevented a number of products that I think would have been really
cool from being developed because they just aren’t practical without
end to end addressing.

A routable GUA for every device…Yes, yes, please yes!!!
Not necessarily reachable from outside (stateful inspection
can still take care of that, you don’t have to mutilate the packet
headers in the process).

> And if they change ISP they will get new range?

Yes. It’s all dynamic addressed anyway, so who cares?

> Doesnt sounds nice to me.. But I guess I its just me

What’s the difference between keeping the same NAT’d v4 with
a new public translated address and a new public address other
than easier event correlation, readable audit logs, and consistency?

> 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 taskforce ;)

Sure, but it wasn’t expected to be a global consumer network. It was intended
to be an R network shared primarily among the military and universities and
a few other research institutions.

> Hah, multicast... Ill skip it.
> 
> Followed change to support CIDR, Internet was still small and considered
> R field...

CIDR was the precursor to NAT largely as a result of the progress of the same
forces that got us where we are today… The internet becoming popular among
audiences it was never originally intended to reach.

> 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.

Well, if you just want an IPv6 complaint fest, then you should probably go find
one of the various lists dedicated to doing that. On NANOG, you’re more likely
to get a balanced practical set of opinions from operators discussing both the
good and the bad with a healthy dose of the recognition that IPv4 is a dead
end whether people want to admit it or not.

Owen

> 
> 
> -- 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 fixed in IPv4 and have nothing to do with ND vs.
> ARP. Table overflows are (not really an issue in my experience) the
> result of a larger address space than the memory available for the L2
> forwarding table on switches or the ND table on hosts. This isn˙˙t due
> to a difference in ND vs. ARP. It is due to the fact that there are no
> 64-bit networks in IPv4, but they are commonplace in IPv6.
> 
> Mostly this has been solved in software by managing table discards more
> effectively.
> 
>> IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some 
>> issues. If this is not the case, im sorry. Its been a while when I last time
>> played with IPv6...
> 
> I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any 
> significant
> problems with it other than some minor inconveniences introduced by the 
> ability
> to have different DUID types and vendors doing semi-obnoxious things along 
> that
> line.
> 
>> IPv6 interop: yeah, I agree here.. 

Re: IPv6 woes - RFC

[Masataka Ohta]

Mark Andrews 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.


Do you mean, because of hole punching, "not routable" does not mean
that it is "not reachable from outside"?


And if they change ISP they will get new range?


Yes!


The problem is that IPv6 was promised to perform *AUTOMATIC*
*RENUMBERING*, with which, even if address ranges change, all
the configuration information, including those for DNS glues,
can be automatically updated.

With careful design by real experts, it is possible to design
such a protocol even with IPv4 but IPv6 "committee" naturally
abandoned to do so with IPv6.

Masataka Ohta

Re: IPv6 woes - RFC

[Mark Andrews]

> 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 taskforce ;)
> 
> Hah, multicast... Ill skip it.
> 
> Followed change to support CIDR, Internet was still small and considered
> R 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 fixed in IPv4 and have nothing to do with ND vs.
> ARP. Table overflows are (not really an issue in my experience) the
> result of a larger address space than the memory available for the L2
> forwarding table on switches or the ND table on hosts. This isn˙˙t due
> to a difference in ND vs. ARP. It is due to the fact that there are no
> 64-bit networks in IPv4, but they are commonplace in IPv6.
> 
> Mostly this has been solved in software by managing table discards more
> effectively.
> 
>> IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some 
>> issues. If this is not the case, im sorry. Its been a while when I last time
>> played with IPv6...
> 
> I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any 
> significant
> problems with it other than some minor inconveniences introduced by the 
> ability
> to have different DUID types and vendors doing semi-obnoxious things along 
> that
> line.
> 
>> IPv6 interop: yeah, I agree here.. But people involved with IPv6 should 
>> think about some external IPv4 interop.. Internet was exploding at 1997..
>> Maybe they had hope that everyone upgrade like in CIDR case. And maybe it 
>> could happen if IPv6 wasnt so alien ;)
> 
> It was thought about˙˙ It was considered. It was long pondered. Problem was,
> nobody could come up with a way to overcome the fact that you can˙˙t put
> 128 bits of data in a 32 bit field without loss.
> 
> IPv6 really isn˙˙t so alien, so I don˙˙t buy that argument. The software 
> changes
> necessary to implement IPv6 were significantly bigger than CIDR and IPv6
> affected applications, not just network. There was no way around these
> 

Re: EXTERNAL: Re: VoIP Provider DDoSes

[Eric Kuhnke]

For those persons with voip.ms accounts, the DDoS-protected servers are in
their control panel with a green checkmark next to them as recommended
servers.

Now it looks like part of the DDoS has shifted to bandwidth.com.

On Mon, Sep 27, 2021 at 4:40 PM Mike Hammett  wrote:

> It seems like Cloudflare can do something now too because VoIP.MS is now
> routed through Cloudflare for their new servers.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"Ray Orsini" 
> *To: *"Mike Hammett" , "NANOG" 
> *Sent: *Wednesday, September 22, 2021 8:15:51 AM
> *Subject: *Re: EXTERNAL: Re: VoIP Provider DDoSes
>
> Yes there are. I was about to message Steve about the correction. Corero
> and path.net are options. There are others.
> [image: OIT Website] 
> Ray Orsini​
> Chief Executive Officer
> OIT, LLC
>  *305.967.6756 x1009* <305.967.6756%20x1009>  |   *305.571.6272*
>  *r...@oit.co*   |  [image: https://www.oit.co]
>  * www.oit.co* 
>  oit.co/ray
> [image: Facebook] 
> [image: LinkedIn] 
> [image: Twitter] 
> [image: YouTube] 
>
> *How are we doing? We'd love to hear your feedback. https://go.oit.co/review*
> 
> --
> *From:* NANOG  on behalf of Mike
> Hammett 
> *Sent:* Wednesday, September 22, 2021 9:08:22 AM
> *To:* NANOG 
> *Subject:* EXTERNAL: Re: VoIP Provider DDoSes
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe. If you are unsure, please forward this email to the
> CSE team for review.
>
> https://twit.tv/shows/security-now/episodes/837?autostart=false
>
>
> It looks like Security Now covered this yesterday. They claimed that,
> "There  is  currently  no  provider of  large  pipe  VoIP  protocol  DDoS
>  protection."
>
> Are any of the cloud DDoS mitigation services offering a service like this.
>
> --
> *From: *"Mike Hammett" 
> *To: *"NANOG" 
> *Sent: *Tuesday, September 21, 2021 4:19:42 PM
> *Subject: *VoIP Provider DDoSes
>
> As many may know, a particular VoIP supplier is suffering a DDoS.
> https://twitter.com/voipms
>
> Are your garden variety DDoS mitigation platforms or services equipped to
> handle DDoSes of VoIP services? What nuances does one have to be cognizant
> of? A WAF doesn't mean much to SIP, IAX2, RTP, etc.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>
>

Re: 100GbE beyond 40km

[Dan Murphy]

> Looking at EDFA options... they are all ~1500nm as far as I can tell. Is
there a specific model you are talking about?

Yeah, that is a consequence of how the EDFA technology works. It really
only works in the C-band and sometimes the L-band, depending on how it's
manufactured. If you contact one of the manufacturers on this list they
should be able to help you with solutions engineering.
You would essentially be looking at a 10x 10G LAG *or* a single 100G
channelized optic (which are a thing, just pay attention to how they
achieve that, and that it runs at 100GHz)

There are other amplifier systems, like the one Brandon mentioned, which
operates via another mechanism. Personally, I would recommend the EDFA
system for two reasons, it's more commoditized, and depending on the model
you purchase, you will have some. spare DWDM channels. You might not need
it today, but man is it nice to have that extra capacity sitting there.

If you do go for a super extended range optic (like what Brandon
mentioned), make sure the pluggable power draw is within range of your
gear. No point in burning out an expensive optic and your gear.

I could go on about chromatic dispersion for days, I think that is so
interesting, but a little outside the scope of this chain. Whatever
manufacturer you engage with will help with that. Thankfully this tech has
gotten to the point where we can just slap that module in and not worry
about what is actually going on behind the scenes.

- Dan

On Mon, Sep 27, 2021 at 3:43 PM Pierre LANCASTRE 
wrote:

> Hi
>
> +1 for SmartOptics products. Got M-1601 + optics, did the job very well
>
> Pierre
>
> Le lun. 27 sept. 2021 à 20:52, Kevin Menzel via NANOG  a
> écrit :
>
>> We’ve had DCP-M boxes in service for a few years now on our +40km links,
>> with their PAM4 100Gb optics. It’s been SO easy.
>>
>> If I had the money, we’d throw DCP-M boxes at every link we have.
>>
>>
>>
>> -Kevin Menzel
>>
>>
>>
>> *From:* NANOG  *On
>> Behalf Of *Joe Freeman
>> *Sent:* September 24, 2021 17:07
>> *To:* Randy Carpenter 
>> *Cc:* nanog 
>> *Subject:* Re: 100GbE beyond 40km
>>
>>
>>
>> This message was sent from outside of Sheridan College. Please be careful
>> when opening attachments, clicking links, or responding to requests for
>> information.
>>
>>
>>
>> Open Line Systems can get you to 80K with a 100G DWDM Optic (PAM4) -
>>
>>
>>
>> I've used a lot of SmartOptics DCP-M40 shelves for this purpose. They
>> also have transponders that allow you to go from a QSFP28 to CFP to do
>> coherent 100G out to 120Km using the DCP-M40, without a need for regen or
>> extra amps in line.
>>
>>
>>
>> The DCP-M40 is a 1RU box. It looks like a deep 40ch DWDM filter but
>> includes a VAO, EDFA amp, and a WSS I think.
>>
>>
>>
>> On Fri, Sep 24, 2021 at 4:40 PM Randy Carpenter 
>> wrote:
>>
>>
>> How is everyone accomplishing 100GbE at farther than 40km distances?
>>
>> Juniper is saying it can't be done with anything they offer, except for a
>> single CFP-based line card that is EOL.
>>
>> There are QSFP "ZR" modules from third parties, but I am hesitant to try
>> those without there being an equivalent official part.
>>
>>
>> The application is an ISP upgrading from Nx10G, where one of their fiber
>> paths is ~35km and the other is ~60km.
>>
>>
>>
>> thanks,
>> -Randy
>>
>>

-- 
Daniel Murphy
Senior Data Center Engineer
(646) 698-8018

Re: IPv6 woes - RFC

[borg]

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?
And if they change ISP they will get new range?
Doesnt sounds nice to me.. But I guess I its just me

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 taskforce ;)

Hah, multicast... Ill skip it.

Followed change to support CIDR, Internet was still small and considered
R 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 fixed in IPv4 and have nothing to do with ND vs.
ARP. Table overflows are (not really an issue in my experience) the
result of a larger address space than the memory available for the L2
forwarding table on switches or the ND table on hosts. This isn˙˙t due
to a difference in ND vs. ARP. It is due to the fact that there are no
64-bit networks in IPv4, but they are commonplace in IPv6.

Mostly this has been solved in software by managing table discards more
effectively.

> IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some 
> issues. If this is not the case, im sorry. Its been a while when I last time
> played with IPv6...

I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any significant
problems with it other than some minor inconveniences introduced by the ability
to have different DUID types and vendors doing semi-obnoxious things along that
line.

> IPv6 interop: yeah, I agree here.. But people involved with IPv6 should 
> think about some external IPv4 interop.. Internet was exploding at 1997..
> Maybe they had hope that everyone upgrade like in CIDR case. And maybe it 
> could happen if IPv6 wasnt so alien ;)

It was thought about˙˙ It was considered. It was long pondered. Problem was,
nobody could come up with a way to overcome the fact that you can˙˙t put
128 bits of data in a 32 bit field without loss.

IPv6 really isn˙˙t so alien, so I don˙˙t buy that argument. The software changes
necessary to implement IPv6 were significantly bigger than CIDR and IPv6
affected applications, not just network. There was no way around these
two facts. The IPv6 network stack did get adopted and implemented nearly
as fast as CIDR and virtually every OS, Switch, Router has had IPv6 support
for quite some time now at the network stack level. It is applications and
content providers that are lagging and they never did anything for CIDR.

> As for IPv4 vs IPv6 complexity, again, why repeat history.

What complexity?

> Biggest IPv4
> mistake was IPv4 being classfull. It was fixed by bringing CIDR into game.

No, biggest IPv4 mistake was 32-bit addresses. A larger address would have been
inconvenient in hardware at the time, but it would have made IPv4 much more
scalable and would have allowed it to last significantly longer.

> (Another big mistake was class E reservation...)