- Test - lists.nanog.org

QUIC traffic throttled on AT&T residential
by Daniel Sterling 06 Jun '20

06 Jun '20

I've AT&T fiber (in RTP, NC) (AS7018) and I notice UDP QUIC traffic from google (esp. youtube) becomes very slow after a time. This especially occurs with ipv4 connections. I'm not the only one to notice; a web search for e.g. "Extremely Poor Youtube TV Performance" notes the issue. I assume traffic is being throttled on AT&T's side. And it's not done with their CPE; I'm bypassing their NAT box and connecting my laptop directly to the ONT. A quick google search shows people are aware that QUIC can look like DoS traffic -- but how widely known is this problem? It may become worse if / when sites transition to HTTP/3 For now I reject UDP 443 on the client firewall. Applications using QUIC client libraries then fallback to TCP. This works well and I have no issues with latency or throughput when using TCP. May I naively ask if Google staff are working with AT&T to address this? -- Dan

33 78

Weekly Routing Table Report
by cscora＠apnic.net 05 Jun '20

05 Jun '20

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-stats(a)lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith <pfsinoz(a)gmail.com>. Routing Table Report 04:00 +10GMT Sat 06 Jun, 2020 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 813692 Prefixes after maximum aggregation (per Origin AS): 308952 Deaggregation factor: 2.63 Unique aggregates announced (without unneeded subnets): 396724 Total ASes present in the Internet Routing Table: 68243 Prefixes per ASN: 11.92 Origin-only ASes present in the Internet Routing Table: 58615 Origin ASes announcing only one prefix: 24432 Transit ASes present in the Internet Routing Table: 9628 Transit-only ASes present in the Internet Routing Table: 316 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 46 Max AS path prepend of ASN ( 22394) 38 Prefixes from unregistered ASNs in the Routing Table: 836 Number of instances of unregistered ASNs: 838 Number of 32-bit ASNs allocated by the RIRs: 31936 Number of 32-bit ASNs visible in the Routing Table: 26324 Prefixes from 32-bit ASNs in the Routing Table: 121260 Number of bogon 32-bit ASNs visible in the Routing Table: 14 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 549 Number of addresses announced to Internet: 2842667264 Equivalent to 169 /8s, 111 /16s and 169 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 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: 274022 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 214366 Total APNIC prefixes after maximum aggregation: 62356 APNIC Deaggregation factor: 3.44 Prefixes being announced from the APNIC address blocks: 207911 Unique aggregates announced from the APNIC address blocks: 85914 APNIC Region origin ASes present in the Internet Routing Table: 10591 APNIC Prefixes per ASN: 19.63 APNIC Region origin ASes announcing only one prefix: 2953 APNIC Region transit ASes present in the Internet Routing Table: 1562 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 27 Number of APNIC region 32-bit ASNs visible in the Routing Table: 5670 Number of APNIC addresses announced to Internet: 767894400 Equivalent to 45 /8s, 197 /16s and 35 /24s APNIC AS Blocks 4608-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-141625 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: 237767 Total ARIN prefixes after maximum aggregation: 109331 ARIN Deaggregation factor: 2.17 Prefixes being announced from the ARIN address blocks: 235106 Unique aggregates announced from the ARIN address blocks: 119598 ARIN Region origin ASes present in the Internet Routing Table: 18520 ARIN Prefixes per ASN: 12.69 ARIN Region origin ASes announcing only one prefix: 6774 ARIN Region transit ASes present in the Internet Routing Table: 1915 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 42 Number of ARIN region 32-bit ASNs visible in the Routing Table: 3267 Number of ARIN addresses announced to Internet: 1080751616 Equivalent to 64 /8s, 106 /16s and 246 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 231189 Total RIPE prefixes after maximum aggregation: 107028 RIPE Deaggregation factor: 2.16 Prefixes being announced from the RIPE address blocks: 227801 Unique aggregates announced from the RIPE address blocks: 134036 RIPE Region origin ASes present in the Internet Routing Table: 27130 RIPE Prefixes per ASN: 8.40 RIPE Region origin ASes announcing only one prefix: 11744 RIPE Region transit ASes present in the Internet Routing Table: 3848 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 9204 Number of RIPE addresses announced to Internet: 709254528 Equivalent to 42 /8s, 70 /16s and 93 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-213403 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 106629 Total LACNIC prefixes after maximum aggregation: 24862 LACNIC Deaggregation factor: 4.29 Prefixes being announced from the LACNIC address blocks: 107737 Unique aggregates announced from the LACNIC address blocks: 46584 LACNIC Region origin ASes present in the Internet Routing Table: 9916 LACNIC Prefixes per ASN: 10.86 LACNIC Region origin ASes announcing only one prefix: 2474 LACNIC Region transit ASes present in the Internet Routing Table: 1871 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 46 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 7493 Number of LACNIC addresses announced to Internet: 174663936 Equivalent to 10 /8s, 105 /16s and 41 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-272796 + ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 22904 Total AfriNIC prefixes after maximum aggregation: 4705 AfriNIC Deaggregation factor: 4.87 Prefixes being announced from the AfriNIC address blocks: 34588 Unique aggregates announced from the AfriNIC address blocks: 10136 AfriNIC Region origin ASes present in the Internet Routing Table: 1400 AfriNIC Prefixes per ASN: 24.71 AfriNIC Region origin ASes announcing only one prefix: 487 AfriNIC Region transit ASes present in the Internet Routing Table: 278 Average AfriNIC Region AS path length visible: 5.1 Max AfriNIC Region AS path length visible: 30 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 690 Number of AfriNIC addresses announced to Internet: 109584896 Equivalent to 6 /8s, 136 /16s and 34 /24s AfriNIC AS Blocks 36864-37887, 327680-329727 & ERX transfers AfriNIC Address Blocks 41/8, 45/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7545 5522 703 643 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4734 4192 73 ERX-CERNET-BKB China Education and Rese 7552 3412 1330 20 VIETEL-AS-AP Viettel Group, VN 9808 3221 9043 61 CMNET-GD Guangdong Mobile Communication 45899 3152 1806 101 VNPT-AS-VN VNPT Corp, VN 7713 2713 831 511 TELKOMNET-AS-AP PT Telekomunikasi Indon 9498 2271 434 224 BBIL-AP BHARTI Airtel Ltd., IN 4766 2265 11101 554 KIXS-AS-KR Korea Telecom, KR 4755 2132 441 193 TATACOMM-AS TATA Communications formerl 9394 2039 4914 20 CTTNET China TieTong Telecommunications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 11492 4438 298 624 CABLEONE, US 7155 4036 264 27 VIASAT-SP-BACKBONE, US 16509 3936 8124 1783 AMAZON-02, US 22773 3562 2969 153 ASN-CXA-ALL-CCI-22773-RDC, US 6327 3374 1324 90 SHAW, CA 16625 3110 1628 2216 AKAMAI-AS, US 209 2431 5076 534 CENTURYLINK-US-LEGACY-QWEST, US 30036 2395 364 258 MEDIACOM-ENTERPRISE-BUSINESS, US 5650 2304 2981 1621 FRONTIER-FRTR, US 26484 2184 137 201 IKGUL-26484, US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5791 1658 138 UNI2-AS, ES 31334 4906 484 13 KABELDEUTSCHLAND-AS, DE 39891 3651 203 20 ALJAWWALSTC-AS, SA 8551 3178 379 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 3031 449 2056 AKAMAI-ASN1, EU 12389 2516 2251 733 ROSTELECOM-AS, RU 9009 2222 234 1212 M247, GB 34984 2129 353 562 TELLCOM-AS, TR 13188 1604 100 35 TRIOLAN, UA 61317 1235 140 551 ASDETUK http://www.heficed.com, GB Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 6658 3325 602 Uninet S.A. de C.V., MX 10620 3354 529 506 Telmex Colombia S.A., CO 11830 2666 369 63 Instituto Costarricense de Electricidad 6503 1687 327 388 Axtel, S.A.B. de C.V., MX 7303 1517 988 251 Telecom Argentina S.A., AR 13999 1417 513 331 Mega Cable, S.A. de C.V., MX 28573 1369 2243 206 CLARO S.A., BR 6147 1149 379 39 Telefonica del Peru S.A.A., PE 3816 1107 570 148 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 955 111 68 Alestra, S. de R.L. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1485 393 22 LINKdotNET-AS, EG 24835 1119 522 26 RAYA-AS, EG 36992 1085 1539 76 ETISALAT-MISR, EG 36903 900 472 91 MT-MPLS, MA 29571 606 68 11 ORANGE-COTE-IVOIRE, CI 6713 551 1863 34 IAM-AS, MA 37342 479 32 1 MOVITEL, MZ 36935 409 522 44 Vodafone-, EG 23889 365 231 15 MauritiusTelecom, MU 15399 364 45 12 WANANCHI-, KE Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 6658 3325 602 Uninet S.A. de C.V., MX 12479 5791 1658 138 UNI2-AS, ES 7545 5522 703 643 TPG-INTERNET-AP TPG Telecom Limited, AU 31334 4906 484 13 KABELDEUTSCHLAND-AS, DE 4538 4734 4192 73 ERX-CERNET-BKB China Education and Rese 11492 4438 298 624 CABLEONE, US 7155 4036 264 27 VIASAT-SP-BACKBONE, US 16509 3936 8124 1783 AMAZON-02, US 39891 3651 203 20 ALJAWWALSTC-AS, SA 22773 3562 2969 153 ASN-CXA-ALL-CCI-22773-RDC, US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggregation summary ----------------------------------------- ASN No of nets Net Savings Description 12479 5791 5653 UNI2-AS, ES 31334 4906 4893 KABELDEUTSCHLAND-AS, DE 7545 5522 4879 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4734 4661 ERX-CERNET-BKB China Education and Research Net 7155 4036 4009 VIASAT-SP-BACKBONE, US 11492 4438 3814 CABLEONE, US 39891 3651 3631 ALJAWWALSTC-AS, SA 22773 3562 3409 ASN-CXA-ALL-CCI-22773-RDC, US 7552 3412 3392 VIETEL-AS-AP Viettel Group, VN 6327 3374 3284 SHAW, CA Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Net Originated Transit AS Transit AS Name 62828 UNALLOCATED 8.21.130.0/24 3356 LEVEL3, US 393266 UNALLOCATED 8.23.52.0/24 174 COGENT-174, US 62485 UNALLOCATED 8.23.229.0/24 3356 LEVEL3, US 32985 UNALLOCATED 8.28.31.0/24 3356 LEVEL3, US 394936 UNALLOCATED 8.33.224.0/24 174 COGENT-174, US 23061 UNALLOCATED 8.39.119.0/24 3356 LEVEL3, US 26584 UNALLOCATED 8.42.62.0/23 209 CENTURYLINK-US-LEGACY-QWEST, 395438 UNALLOCATED 8.42.206.0/24 3356 LEVEL3, US 46766 UNALLOCATED 8.44.208.0/24 3356 LEVEL3, US 40544 UNALLOCATED 12.0.33.0/24 6461 ZAYO-6461, US Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 192.88.99.0/24 6939 HURRICANE, US Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Unassigned Network ASN Information AS Name 27.100.7.0/24 Origin: 56096 UNASSIGNED Transit: 45455 TH-2S1N-AP Two S One N Co Ltd, Internet 27.126.156.0/22 Origin: 55827 UNASSIGNED Transit: 9930 TTNET-MY TIME dotCom Berhad, MY 27.126.156.0/23 Origin: 55827 UNASSIGNED Transit: 9930 TTNET-MY TIME dotCom Berhad, MY 27.126.158.0/23 Origin: 55827 UNASSIGNED Transit: 9930 TTNET-MY TIME dotCom Berhad, MY 41.67.192.0/18 Origin: 15964 CAMNET-AS, CM Transit: 37662 WIOCC-AS, MU Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:9 /9:11 /10:38 /11:99 /12:287 /13:580 /14:1170 /15:1916 /16:13360 /17:8233 /18:13940 /19:25887 /20:41273 /21:48462 /22:100713 /23:83520 /24:472909 /25:1285 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4794 5791 UNI2-AS, ES 31334 4751 4906 KABELDEUTSCHLAND-AS, DE 11492 3519 4438 CABLEONE, US 6327 3164 3374 SHAW, CA 7155 3128 4036 VIASAT-SP-BACKBONE, US 39891 2801 3651 ALJAWWALSTC-AS, SA 22773 2773 3562 ASN-CXA-ALL-CCI-22773-RDC, US 8551 2636 3178 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 8151 2349 6658 Uninet S.A. de C.V., MX 30036 2138 2395 MEDIACOM-ENTERPRISE-BUSINESS, US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1772 2:1182 3:30 4:19 5:3382 6:52 8:1421 9:1 11:1 12:1785 13:507 14:2311 15:72 16:8 17:294 18:81 20:106 23:3651 24:2285 25:2 27:2525 31:3086 32:127 34:3 35:41 36:938 37:3265 38:2029 39:418 40:128 41:3616 42:899 43:2135 44:208 45:14371 46:3681 47:293 49:1457 50:1451 51:93 52:1052 54:240 55:672 56:6 57:52 58:1841 59:1168 60:741 61:2290 62:2082 63:1984 64:5127 65:2299 66:4969 67:2870 68:1185 69:3938 70:1408 71:679 72:2873 74:2601 75:1447 76:668 77:2898 78:1653 79:2364 80:1935 81:1625 82:1318 83:1311 84:1235 85:2612 86:539 87:1734 88:1089 89:2752 90:381 91:7959 92:1522 93:2506 94:2714 95:3897 96:1242 97:331 98:932 99:977 100:87 101:1003 102:941 103:23789 104:3436 105:395 106:879 107:1997 108:713 109:3671 110:1829 111:2044 112:1600 113:1358 114:1522 115:1828 116:1792 117:2196 118:2131 119:1711 120:856 121:1043 122:2427 123:1994 124:1553 125:2023 128:1364 129:1185 130:644 131:1839 132:750 133:302 134:1313 135:287 136:614 137:851 138:2187 139:993 140:673 141:987 142:925 143:1216 144:1013 145:305 146:1494 147:1029 148:2122 149:1190 150:872 151:1331 152:1493 153:390 154:4658 155:1053 156:3122 157:1126 158:845 159:1969 160:1893 161:1049 162:3087 163:830 164:1458 165:1290 166:555 167:1634 168:3544 169:546 170:4210 171:771 172:1936 173:2547 174:992 175:1042 176:2699 177:4238 178:3054 179:1462 180:2271 181:2465 182:3083 183:1166 184:2430 185:16436 186:3730 187:2787 188:4096 189:2339 190:8765 191:1317 192:10378 193:7536 194:6184 195:4409 196:3216 197:1964 198:6084 199:5916 200:7232 201:5261 202:10492 203:10249 204:4579 205:3105 206:3207 207:3277 208:4067 209:4434 210:3992 211:2023 212:3371 213:3137 214:1189 215:62 216:6052 217:2425 218:874 219:613 220:2040 221:935 222:993 223:1487 End of report

1 0

Comcast Midwest
by David Ratkay 03 Jun '20

03 Jun '20

Big outage for comcast customers in the midwest, anyone have an idea what the problem is? BGP related?

1 0

PlayStation Web Technical Contact
by Justin Ouellette 03 Jun '20

03 Jun '20

Does anyone have a good technical contact at PlayStation? Our customers are having some issues accessing their website from one of our prefixes (/22). I have not had any luck contacting anyone that wants to help resolve the issue.

2 1

Proposal of enhancement on the RIRs/NRO delegation File format/info
by Douglas Fischer 02 Jun '20

02 Jun '20

Hello everyone P.S .: I apologize, but I write for multiple email lists, precisely because it is a topic that interests multiple regions. P.S.2: The objective in this proposal is to make feasible the creation of validation mechanisms for the creation of IRR Route / Route6 Objects, without requiring any type of change in the protocols currently in use. Just adjusting the information already public and available. I am from Brazil, and Registro.BR (National Internet Registry) provides a file[1] of delegations in a format slightly different from the official NRO format [2]. In the link below [1] it is possible to see a list with an unequivocal association between the ASN and the IP block delegated to the owner. [1] ftp://ftp.registro.br/pub/numeracao/origin/nicbr-asn-blk-latest.txt Note: Registro.BR delegations are also published in the official NRO format, included in LACNIC's public archive [3] to which NIC.BR is linked. This unequivocal link allows us an extra layer of validation with respect to Hijack of prefixes, and also the creation of INVALID Route / Route6 objects in IRR. Inspired by this file format[1], I decided to take a closer look at the official NRO format. As expected, I was able to establish a link between the Owner of the ASN, and the Owner of the IPv4 / IPv6. However, this link is NOT unambiguous. The attribute that makes this link is Opaque-ID and is described on NRO oficial format file[2]. This attribute referred to an organization that holds some type of numerical resource on the Internet. In 90-95% of cases, the ASN <-> OpaqueID <-> InetNum link is assertive. However, there are cases in which this association is not sufficient to be assertive. A) Delegations of IPv4 and / or IPv6 blocks to end users without the delegation of an ASN to that institution. - These cases do not allow an assertive link between ASN and IPv4 / IPv6, so they ARE NOT THE FOCUS of my analysis. B) Organizations that own multiple sets of ASN <-> InetNum. B.1 - The cause that I believe to be the most common for this is mergers and acquisitions of organizations, where despite that OpaqueID referring to the same organization (CNPJ / EIN / RUC / Fiscal Number), the ASN sets <- > InetNum are from different Service Providers (sometimes even in geographically different regions). B.2 - But there are other examples of this, such as the need for specific segmentation of networks within the same organization. By consulting in the Whois databases some of these ASNs, it is possible to verify that the linking information between Autnum <-> Inetnum exists within the whois databases. fischer-mac-3: ~ fischerdouglas $ whois -h whois.lacnic.net AS28000 | grep num: aut-num: AS28000 inetnum: 179.0.156 / 22 inetnum: 200.7.84 / 23 inetnum: 2001: 13c7: 7001 :: / 48 The suggestion itself: --------------------- In the official format of the NRO [2], the "Extensions" column provides for the addition of data that was not yet foreseen. In this column, in the IPv4 and IPv6 resource lines, if that block is associated with any ASN, add the ASN to which that block is associated. The questions: ------------- - Any consideration about that? - What is the path to reach the right persons to make a official proposal? P.S.3: Yes, I know that we have entered the era of RPKI. Yes, I know that probably in 5-6 years we will have another 90% of DFZ as VALID. But I believe that such an action would require minimal effort, ample result, and would also serve as an incentive for the diversifying Owner of IP blocks to move and create their ROAs. Examples of organizations with multiple sets of AutNum<->InetNum: B.1.a "TELEFÔNICA BRASIL S.A" with 9 ASNs 10429, 11419, 16885, 16911, 18881, 19182, 22092, 26599, 27699. B.1.b "Telecom Argentina S.A." with 11 ASNs 7303, 7934, 10318, 10481, 10895, 10983, 11356, 12264, 21590, 26608, 27871. B.2.a "Núcleo de Inf. E Coord. Do Ponto BR - NIC.BR" with 16 ASNs 10906, 11284, 11431, 11644, 11752, 12136, 13874, 14026, 14650, 20121, 22548, 26162, 263044, 28345, 53035, 61580. B.2.b "LACNIC - Latin American and Caribbean IP address" with 7 ASNs. 28000, 28001, 28002, 28119, 52224, 264845, 264846 [2] https://www.nro.net/wp-content/uploads/nro-extended-stats-readme5.txt [3] ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-extended-latest -- Douglas Fernando Fischer Engº de Controle e Automação

2 2

Verizon Wireless
by Mark Stevens 02 Jun '20

02 Jun '20

Good morning, If a Verizon Wireless engineer covering NJ/NYC could contact me offline it would be much appreciated. We are currently seeing one way voice paths from VZW in 3 NJ tandems. Thanks Mark

1 0

Contact at Ubiquiti Networks?
by j k 02 Jun '20

02 Jun '20

Does anyone have a good contact at Ubiquity Networks? Finding a pattern I don't like. Joe Klein "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) "I never lose. I either win or learn" - Nelson Mandela

9 9

Re: Contact at Ubiquiti Networks?
by Mike Hammett 01 Jun '20

01 Jun '20

That is a big problem. In terms of their UniFi product line, there are no reasonable alternatives. Upper management is the biggest problem. They have severe ADD. A ton of companies have these kinds of issues. They just plain don't hire enough people in the right areas to really excel. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Ben P" <bp(a)list-subs.com> To: "Mike Hammett" <nanog(a)ics-il.net> Cc: "j k" <jsklein(a)gmail.com>, "NANOG list" <nanog(a)nanog.org> Sent: Tuesday, May 26, 2020 5:01:36 AM Subject: Re: Contact at Ubiquiti Networks? Agree 1000% with the sentiments expressed by Mike. Unfortunately despite much research I’ve been unable to find a suitable replacement vendor. All the other vendors seem to want to ram cloud-management down your throat which I absolutely do not want. My network, my control, not under the auspices of someone else’s magic cloud. On 25 May 2020, at 21:21, Mike Hammett < nanog(a)ics-il.net > wrote: The company has mostly fallen apart. Their sales are going up, but their responsiveness and customer support have been declining over the last five years. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "j k" < jsklein(a)gmail.com > To: "NANOG list" < nanog(a)nanog.org > Sent: Monday, May 25, 2020 3:16:36 PM Subject: Contact at Ubiquiti Networks? Does anyone have a good contact at Ubiquity Networks? Finding a pattern I don't like. Joe Klein "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) "I never lose. I either win or learn" - Nelson Mandela

16 24

RE: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs)
by Templin (US), Fred L 01 Jun '20

01 Jun '20

NBMA is not necessarily a one-size-fits-all category, and it looks like multiple proposals are considering models for NBMA links. AERO and OMNI define an NBMA link model for virtual links and do define the operation of IPv6 ND over those links in ways that go beyond RFC5942. This is encouraged in RFC4861 where it says: “Unless specified otherwise (in a document that covers operating IP over a particular link type) this document applies to all link types. However, because ND uses link-layer multicast for some of its services, it is possible that on some link types (e.g., Non-Broadcast Multi-Access (NBMA) links), alternative protocols or mechanisms to implement those services will be specified (in the appropriate document covering the operation of IP over a particular link type).” Fred From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Monday, June 01, 2020 7:27 AM To: Wes Beebee (wbeebee) <wbeebee=40cisco.com(a)dmarc.ietf.org>; Etienne-Victor Depasquale <edepa(a)ieee.org> Cc: NANOG <nanog(a)nanog.org>; ipv6(a)ietf.org Subject: RE: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs) I take the “there was no NBMA” off, then, Wes, you’re correct. I’ll add a ref to RFC 5942 in section 4.4 that discusses the use of on-link flag. Note that Hub and spoke is a very limited conception of NBMA. Think of an IOT network such as a RPL domain, or a frame relay network with OSPFv2 NBMA / P2MP models. It takes quite a bit more than resetting the on-link flag to enable IPv6 ND on those NBMA networks, though it is indeed necessary. This is what I tried to express too concisely. Keep safe, Pascal PS For NBMA, RFC 4861 clearly says non-broadcast multiple access (NBMA) - Redirect, Neighbor Unreachability Detection and next-hop determination should be implemented as described in this document. Address resolution, and the mechanism for delivering Router Solicitations and Advertisements on NBMA links are not specified in this document. Note that if hosts support manual configuration of a list of default routers, hosts can dynamically acquire the link-layer addresses for their neighbors from Redirect messages. From: Wes Beebee (wbeebee) <wbeebee=40cisco.com(a)dmarc.ietf.org<mailto:wbeebee=40cisco.com@dmarc.ietf.org>> Sent: lundi 1 juin 2020 16:00 To: Pascal Thubert (pthubert) <pthubert(a)cisco.com<mailto:pthubert@cisco.com>>; Etienne-Victor Depasquale <edepa(a)ieee.org<mailto:edepa@ieee.org>> Cc: NANOG <nanog(a)nanog.org<mailto:nanog@nanog.org>>; ipv6(a)ietf.org<mailto:ipv6@ietf.org> Subject: Re: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs) RFC 5942 outlines how NBMA works with Neighbor Discovery. Using this RFC, IPv6 has been deployed in NBMA networks (DOCSIS) with 10 million+ subscribers without any problems. - Wes From: ipv6 <ipv6-bounces(a)ietf.org<mailto:ipv6-bounces@ietf.org>> on behalf of "Pascal Thubert (pthubert)" <pthubert=40cisco.com(a)dmarc.ietf.org<mailto:pthubert=40cisco.com@dmarc.ietf.org>> Date: Sunday, May 31, 2020 at 8:29 AM To: Etienne-Victor Depasquale <edepa(a)ieee.org<mailto:edepa@ieee.org>> Cc: NANOG <nanog(a)nanog.org<mailto:nanog@nanog.org>>, "ipv6(a)ietf.org<mailto:ipv6@ietf.org>" <ipv6(a)ietf.org<mailto:ipv6@ietf.org>> Subject: Re: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs) Cool, that’s the whole point. With IPv6 ND as defined 20+ years ago there couldn’t be NBMA and there couldn’t be MLSN. We have changed that in IoT and we are now trying to generalize to all types of links. There’s a tentative to get the aforementioned draft adopted at 6MAN. If you found it useful please voice support ! Take care, Pascal Le 31 mai 2020 à 13:11, Etienne-Victor Depasquale <edepa(a)ieee.org<mailto:edepa@ieee.org>> a écrit : Pascal, thank you, the draft at https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ is very informative. You hit the nail on the head with your suggestion of confusion between the congruence of link and subnet. However, I followed one of the references (RFC4903) in your draft and it does not help that it (RFC4903) points to RFC4291's assertion that: "Currently IPv6 continues the IPv4 model that a subnet prefix is associated with one link" RFC4903 further states that: "clearly, the notion of a multi-link subnet would be a change to the existing IP model.". I confess: your assertion in the draft that: "In Route-Over Multi-link subnets (MLSN) [RFC4903], routers federate the links between nodes that belong to the subnet, the subnet is not on-link and it extends beyond any of the federated links" is news to me. Best regards, Etienne On Sat, May 30, 2020 at 1:39 PM Pascal Thubert (pthubert) <pthubert(a)cisco.com<mailto:pthubert@cisco.com>> wrote: Hello Etienne Victor Maybe you’re confusing link and a subnet? This is discussed at length here: https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ RPL can route inside a subnet using host routes. This is how a multi link subnet can be made to work... Please let me know if the draft above helped and whether it is clear enough. The best way for that discussion would be to cc 6MAN. Keep safe, Pascal Le 30 mai 2020 à 10:03, Etienne-Victor Depasquale <edepa(a)ieee.org<mailto:edepa@ieee.org>> a écrit : Thank you Carsten, and thank you Pacal. Your replies are valuable and packed with insight. I'll wrap up with how I interpret RPL's behaviour in terms of IP hops. On one hand, RFC6775 defines a route-over topology as follows: "A topology where hosts are connected to the 6LBR through the use of intermediate layer-3 (IP) routing. Here, hosts are typically multiple IP hops away from a 6LBR. The route-over topology typically consists of a 6LBR, a set of 6LRs, and hosts." If RPL is route-over by definition, then RFC6775 would imply that there are typically multiple IP hops between a leaf and the border router. On the other hand, there at least two contradictions (which I justify after stating them): (a) RFC6550 states that "RPL also introduces the capability to bind a subnet together with a common prefix and to route within that subnet." (b) Reduction of a DODAG to a single subnet prefix, albeit only only one parent-child relationship deep, is clearly shown at Contiki-NG's Github page (deep dive section). The hinge on which my understanding revolves is that an IP hop traverses a router and ***results in a change of prefix of the link on which the packet travels*** : --------<incoming packet; link prefix = p1>------><router> --------<outgoing packet; link prefix = p2>------> With RPL, the "hop" would look like as shown below: --------<incoming packet; link prefix = p1>------<router> --------<outgoing packet; link prefix = p1>------ There seems to be a change in the meaning associated with "IP hop". I guess that I can reconcile both cases through the observation that RPL actually does apply to a single, NBMA link and therefore the IP prefix ***is*** the same. Then again, calling the RPL device involved in the packet forwarding by the name "router" feels like an uncomfortable stretch. Don't routers sit at the meeting point of different layer 2 links? Cheers, Etienne On Fri, May 29, 2020 at 10:39 PM Pascal Thubert (pthubert) <pthubert(a)cisco.com<mailto:pthubert@cisco.com>> wrote: Hello Etienne You may see ND as the host to * interface for any network and RPL as the router to router interface when the network is NBMA. Some of us cared about the interworking. Look at the RPL Unaware leaf I-draft and you’ll see that I’m sure. Keep safe, Pascal > Le 29 mai 2020 à 20:28, Carsten Bormann <cabo(a)tzi.org<mailto:cabo@tzi.org>> a écrit : > > Hi Etienne, > > I’m also not sure many of the classical network operators assembled in NANOG work with 6LoWPANs today, but I still can answer your question. > >> While trying to build a holistic view of LoWPANs, I'm consulting the IETF's informational and standards documents. >> >> I'm struck by the impression that, despite the significance of RFC6775's extension of Neighbor Discovery(ND) to low-power and lossy networks (LLNs), >> it is largely ignored by RFC6550 (RPL), with little to no reference to the ontological plane created in RFC6775's terminology section. > > Yes, you could say that. > > ND (Neighbor discovery) describes interfaces between hosts and between hosts and routers. > 6LoWPAN-ND does not use host-to-host interfaces (different from Ethernet, all traffic goes over routers, which RFC 4861 already forsaw in the L — on-link — bit, which isn’t set in 6LoWPAN-ND). > > RFC 6550 was completed at a time when many people who came in from the WSN (wireless sensor network) world thought they could get away with a network that is wholly composed of routers. > Even the “leaf” nodes in the RPL world were participating in the routing protocol and therefore didn’t really need a host-router interface. There was no separate host-router interface in that world, because there were no non-router hosts. > >> (a) router advertisements and router solicitations are substituted by DAG information objects (DIO) and DAG information solicitations (DIS) > > Right, DIO and DAO are router-to-router messages. If there are no hosts (and routers don’t bootstrap themselves as hosts), you don’t need ND. > >> (b) the terms "mesh-under" and "route-over" (widely cited), defined in RFC6775, are absent from RFC6550 > > RFC6550 is route over by definition. Actually, the term was coined by the people working closely with the RPL development; RFC 6775 does appropriate it as 6LoWPAN-ND is applicable in either case. > >> (c) jarringly: RFC6775 describes the route-over topologies as multi-IP-hop, while RFC6550 gathers DODAG nodes within the confines of the same IPv6 prefix as their border router - no multiple IP hops. > > I’m not sure where you get this interpretation: RFC 6550 (RPL) is very much about IP hops. > Maybe you mean the address architecture that was defined explicitly in RFC 6775; RFC 6550 does not really say much about addresses. > > Note that the RPL people have since proceeded to (at least partially) embrace the host-router concept from the IP architecture; RFC 8505 is an update to RFC 6775 that makes 6LoWPAN-ND more palatable to RPL people. > > I have CCed Pascal Thubert who, as a co-author to all three RFCs, certainly will have another perspective on this. > > Grüße, Carsten > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale

1 0

FW: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs)
by Pascal Thubert (pthubert) 01 Jun '20

01 Jun '20

I take the “there was no NBMA” off, then, Wes, you’re correct. I’ll add a ref to RFC 5942 in section 4.4 that discusses the use of on-link flag. Note that Hub and spoke is a very limited conception of NBMA. Think of an IOT network such as a RPL domain, or a frame relay network with OSPFv2 NBMA / P2MP models. It takes quite a bit more than resetting the on-link flag to enable IPv6 ND on those NBMA networks, though it is indeed necessary. This is what I tried to express too concisely. Keep safe, Pascal PS For NBMA, RFC 4861 clearly says non-broadcast multiple access (NBMA) - Redirect, Neighbor Unreachability Detection and next-hop determination should be implemented as described in this document. Address resolution, and the mechanism for delivering Router Solicitations and Advertisements on NBMA links are not specified in this document. Note that if hosts support manual configuration of a list of default routers, hosts can dynamically acquire the link-layer addresses for their neighbors from Redirect messages. From: Wes Beebee (wbeebee) <wbeebee=40cisco.com(a)dmarc.ietf.org<mailto:wbeebee=40cisco.com@dmarc.ietf.org>> Sent: lundi 1 juin 2020 16:00 To: Pascal Thubert (pthubert) <pthubert(a)cisco.com<mailto:pthubert@cisco.com>>; Etienne-Victor Depasquale <edepa(a)ieee.org<mailto:edepa@ieee.org>> Cc: NANOG <nanog(a)nanog.org<mailto:nanog@nanog.org>>; ipv6(a)ietf.org<mailto:ipv6@ietf.org> Subject: Re: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs) RFC 5942 outlines how NBMA works with Neighbor Discovery. Using this RFC, IPv6 has been deployed in NBMA networks (DOCSIS) with 10 million+ subscribers without any problems. * Wes From: ipv6 <ipv6-bounces(a)ietf.org<mailto:ipv6-bounces@ietf.org>> on behalf of "Pascal Thubert (pthubert)" <pthubert=40cisco.com(a)dmarc.ietf.org<mailto:pthubert=40cisco.com@dmarc.ietf.org>> Date: Sunday, May 31, 2020 at 8:29 AM To: Etienne-Victor Depasquale <edepa(a)ieee.org<mailto:edepa@ieee.org>> Cc: NANOG <nanog(a)nanog.org<mailto:nanog@nanog.org>>, "ipv6(a)ietf.org<mailto:ipv6@ietf.org>" <ipv6(a)ietf.org<mailto:ipv6@ietf.org>> Subject: Re: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs) Cool, that’s the whole point. With IPv6 ND as defined 20+ years ago there couldn’t be NBMA and there couldn’t be MLSN. We have changed that in IoT and we are now trying to generalize to all types of links. There’s a tentative to get the aforementioned draft adopted at 6MAN. If you found it useful please voice support ! Take care, Pascal Le 31 mai 2020 à 13:11, Etienne-Victor Depasquale <edepa(a)ieee.org<mailto:edepa@ieee.org>> a écrit : Pascal, thank you, the draft at https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ is very informative. You hit the nail on the head with your suggestion of confusion between the congruence of link and subnet. However, I followed one of the references (RFC4903) in your draft and it does not help that it (RFC4903) points to RFC4291's assertion that: "Currently IPv6 continues the IPv4 model that a subnet prefix is associated with one link" RFC4903 further states that: "clearly, the notion of a multi-link subnet would be a change to the existing IP model.". I confess: your assertion in the draft that: "In Route-Over Multi-link subnets (MLSN) [RFC4903], routers federate the links between nodes that belong to the subnet, the subnet is not on-link and it extends beyond any of the federated links" is news to me. Best regards, Etienne On Sat, May 30, 2020 at 1:39 PM Pascal Thubert (pthubert) <pthubert(a)cisco.com<mailto:pthubert@cisco.com>> wrote: Hello Etienne Victor Maybe you’re confusing link and a subnet? This is discussed at length here: https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ RPL can route inside a subnet using host routes. This is how a multi link subnet can be made to work... Please let me know if the draft above helped and whether it is clear enough. The best way for that discussion would be to cc 6MAN. Keep safe, Pascal Le 30 mai 2020 à 10:03, Etienne-Victor Depasquale <edepa(a)ieee.org<mailto:edepa@ieee.org>> a écrit : Thank you Carsten, and thank you Pacal. Your replies are valuable and packed with insight. I'll wrap up with how I interpret RPL's behaviour in terms of IP hops. On one hand, RFC6775 defines a route-over topology as follows: "A topology where hosts are connected to the 6LBR through the use of intermediate layer-3 (IP) routing. Here, hosts are typically multiple IP hops away from a 6LBR. The route-over topology typically consists of a 6LBR, a set of 6LRs, and hosts." If RPL is route-over by definition, then RFC6775 would imply that there are typically multiple IP hops between a leaf and the border router. On the other hand, there at least two contradictions (which I justify after stating them): (a) RFC6550 states that "RPL also introduces the capability to bind a subnet together with a common prefix and to route within that subnet." (b) Reduction of a DODAG to a single subnet prefix, albeit only only one parent-child relationship deep, is clearly shown at Contiki-NG's Github page (deep dive section). The hinge on which my understanding revolves is that an IP hop traverses a router and ***results in a change of prefix of the link on which the packet travels*** : --------<incoming packet; link prefix = p1>------><router> --------<outgoing packet; link prefix = p2>------> With RPL, the "hop" would look like as shown below: --------<incoming packet; link prefix = p1>------<router> --------<outgoing packet; link prefix = p1>------ There seems to be a change in the meaning associated with "IP hop". I guess that I can reconcile both cases through the observation that RPL actually does apply to a single, NBMA link and therefore the IP prefix ***is*** the same. Then again, calling the RPL device involved in the packet forwarding by the name "router" feels like an uncomfortable stretch. Don't routers sit at the meeting point of different layer 2 links? Cheers, Etienne On Fri, May 29, 2020 at 10:39 PM Pascal Thubert (pthubert) <pthubert(a)cisco.com<mailto:pthubert@cisco.com>> wrote: Hello Etienne You may see ND as the host to * interface for any network and RPL as the router to router interface when the network is NBMA. Some of us cared about the interworking. Look at the RPL Unaware leaf I-draft and you’ll see that I’m sure. Keep safe, Pascal > Le 29 mai 2020 à 20:28, Carsten Bormann <cabo(a)tzi.org<mailto:cabo@tzi.org>> a écrit : > > Hi Etienne, > > I’m also not sure many of the classical network operators assembled in NANOG work with 6LoWPANs today, but I still can answer your question. > >> While trying to build a holistic view of LoWPANs, I'm consulting the IETF's informational and standards documents. >> >> I'm struck by the impression that, despite the significance of RFC6775's extension of Neighbor Discovery(ND) to low-power and lossy networks (LLNs), >> it is largely ignored by RFC6550 (RPL), with little to no reference to the ontological plane created in RFC6775's terminology section. > > Yes, you could say that. > > ND (Neighbor discovery) describes interfaces between hosts and between hosts and routers. > 6LoWPAN-ND does not use host-to-host interfaces (different from Ethernet, all traffic goes over routers, which RFC 4861 already forsaw in the L — on-link — bit, which isn’t set in 6LoWPAN-ND). > > RFC 6550 was completed at a time when many people who came in from the WSN (wireless sensor network) world thought they could get away with a network that is wholly composed of routers. > Even the “leaf” nodes in the RPL world were participating in the routing protocol and therefore didn’t really need a host-router interface. There was no separate host-router interface in that world, because there were no non-router hosts. > >> (a) router advertisements and router solicitations are substituted by DAG information objects (DIO) and DAG information solicitations (DIS) > > Right, DIO and DAO are router-to-router messages. If there are no hosts (and routers don’t bootstrap themselves as hosts), you don’t need ND. > >> (b) the terms "mesh-under" and "route-over" (widely cited), defined in RFC6775, are absent from RFC6550 > > RFC6550 is route over by definition. Actually, the term was coined by the people working closely with the RPL development; RFC 6775 does appropriate it as 6LoWPAN-ND is applicable in either case. > >> (c) jarringly: RFC6775 describes the route-over topologies as multi-IP-hop, while RFC6550 gathers DODAG nodes within the confines of the same IPv6 prefix as their border router - no multiple IP hops. > > I’m not sure where you get this interpretation: RFC 6550 (RPL) is very much about IP hops. > Maybe you mean the address architecture that was defined explicitly in RFC 6775; RFC 6550 does not really say much about addresses. > > Note that the RPL people have since proceeded to (at least partially) embrace the host-router concept from the IP architecture; RFC 8505 is an update to RFC 6775 that makes 6LoWPAN-ND more palatable to RPL people. > > I have CCed Pascal Thubert who, as a co-author to all three RFCs, certainly will have another perspective on this. > > Grüße, Carsten > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale

1 0