The carrier NAT space is 100.64.0.0/10. 100.1.1.1 is legitimately part of
a Verizon /11; the carrier NAT/Shared Address Space netblock is 100.64.0.0/10
(so we can use the range from 100.64.*.* - 100.127.*.*).
(Reference: http://tools.ietf.org/html/rfc6598 )
On Sun, Mar 01, 2015 at 07:37:25PM -0800, Chris Stillson wrote:
> the problem with that is, what if someone from a natted device actually
> wants to contact a machine on the 100/8 network?
>
> Chris
>
> On Sun, Mar 1, 2015 at 5:47 PM, max b <maxb.personal@gmail.com> wrote:
>
> > Hey just wanted to mention that it does appear as though 100.0.0.0/12
> > does get routed by a number of internet hosts:
> >
> > traceroute -n 100.1.1.1
> >> 1 192.168.2.1 16.953 ms 18.672 ms 26.622 ms
> >> 2 192.168.1.1 63.993 ms 66.595 ms 67.210 ms
> >> 3 50.185.26.1 81.620 ms 84.669 ms 87.114 ms
> >> 4 68.87.196.89 91.254 ms 91.479 ms 92.388 ms
> >> 5 68.87.57.221 87.381 ms 68.87.55.229 104.986 ms 68.87.55.225
> >> 106.784 ms
> >> 6 68.85.155.234 109.069 ms 68.85.155.238 91.181 ms 68.85.155.234
> >> 102.066 ms
> >> 7 * * *
> >> 8 68.86.86.102 106.262 ms 106.159 ms 106.481 ms
> >> 9 68.86.82.94 100.819 ms 104.484 ms 101.623 ms
> >> 10 23.30.206.94 139.012 ms 138.273 ms 158.165 ms
> >> 11 130.81.209.171 193.143 ms * *
> >> 12 * * *
> >> 13 100.1.1.1 159.241 ms 155.888 ms 156.733 ms
> >>
> >
> > or
> >
> > traceroute 100.1.1.1
> >> traceroute to 100.1.1.1 (100.1.1.1), 30 hops max, 60 byte packets
> >> 1 192.168.2.1 (192.168.2.1) 41.102 ms 41.890 ms 44.911 ms
> >> 2 192.168.1.1 (192.168.1.1) 50.067 ms 50.663 ms 51.156 ms
> >> 3 50.185.26.1 (50.185.26.1) 60.095 ms 61.839 ms 87.606 ms
> >> 4 GE-2-37-ur01.fremontcev2.ca.sfba.comcast.net (68.87.196.89) 103.734
> >> ms 104.030 ms 177.000 ms
> >> 5 te-0-7-0-21-sur03.oakland.ca.sfba.comcast.net (68.87.57.221)
> >> 176.024 ms te-0-7-0-19-sur03.oakland.ca.sfba.comcast.net (68.85.57.141)
> >> 176.480 ms te-0-7-0-21-sur03.oakland.ca.sfba.comcast.net (68.87.57.221)
> >> 176.684 ms
> >> 6 te-0-2-0-5-ar01.sfsutro.ca.sfba.comcast.net (69.139.199.78) 178.344
> >> ms te-0-2-0-0-ar01.sfsutro.ca.sfba.comcast.net (68.85.155.234) 19.639
> >> ms te-0-2-0-7-ar01.sfsutro.ca.sfba.comcast.net (68.87.194.50) 41.532 ms
> >> 7 * * *
> >> 8 he-2-9-0-0-cr01.losangeles.ca.ibone.comcast.net (68.86.86.102)
> >> 59.336 ms 98.858 ms 98.859 ms
> >> 9 be-13-pe02.11greatoaks.ca.ibone.comcast.net (68.86.82.94) 98.056
> >> ms 102.286 ms 99.433 ms
> >> 10 23.30.206.94 (23.30.206.94) 273.404 ms 274.855 ms 276.308 ms
> >> 11 B200.NWRKNJ-LCR-22.verizon-gni.net (130.81.209.171) 301.458 ms
> >> P0-15-0-0.NWRKNJ-LCR-22.verizon-gni.net (130.81.199.17) 301.773 ms
> >> 302.699 ms
> >> 12 * * *
> >> 13 L101.NWRKNJ-VFTTP-142.verizon-gni.net (100.1.1.1) 378.294 ms
> >> 379.111 ms 378.479 ms
> >>
> >
> > I think we agreed that this is okay as it's supposed to be strictly for
> > internal NAT only, and so any public routing is sort of incidental. Just
> > wanted folks to be apprised of the situation.
> >
> > _______________________________________________
> > mesh-dev mailing list
> > mesh-dev@lists.sudoroom.org
> > https://lists.sudoroom.org/listinfo/mesh-dev
> >
> >
> _______________________________________________
> mesh-dev mailing list
> mesh-dev@lists.sudoroom.org
> https://lists.sudoroom.org/listinfo/mesh-dev
_______________________________________________
mesh-dev mailing list
mesh-dev@lists.sudoroom.org
https://lists.sudoroom.org/listinfo/mesh-dev