Request comment: list of IPs to block outbound

Wed Oct 23 15:09:05 UTC 2019

On 10/23/19 12:16 AM, Måns Nilsson wrote:
> I understand the reasoning. I appreciate the need. I just do not agree 
> with the conclusion to waste a /10 on beating a dead horse. A /24 would 
> have been more appropriate way of moving the cost of ipv6 non-deployment 
> to those responsible. (put in RFC timescale, 6598 is 3000+ RFCen later 
> than the v6 specification. That is a few human-years. There are no 
> excuses for non-compliance except cheapness.)

For better or worse, I think IPv6 deployment is one of those things that 
will likely be completed about the time that spam problem is resolved. 
It's always going to be moving forward.

I don't know if consuming 4+ million IPs for CGN support is warranted or 
not.

The CGN that I've had experience … working with … (let's be polite) … in 
my day job have all been with providers having way more than a /24 worth 
of clients behind it.  As such, they would need to have many (virtual) 
CGN appliances to deal with each of the /24 private networks.  Would a 
/16 be better?  Maybe.  That is 1/64 th of what's allocated now.

I personally would rather people use 100.64/10 instead of squatting on 
other globally routed IPs that they think they will never need to 
communicate with.  (I've seen a bunch of people squat on DoD IP space 
behind CGN.  I think such practice is adding insult to injury and should 
be avoided.

> Easing the operation of CGN at scale serves no purpose except stalling 
> necessary change. It is like installing an electric blanket to cure the 
> chill from bed-wetting.

Much like humans can move passenter plains, even an electric blanket can 
/eventually/ overcome cold wet bed.

-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20191023/57d77912/attachment.bin>