🚀 go-pugleaf

On Thu, 31 Dec 2015, Lukasz Trabinski wrote:

> Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> wrote:
>
>> https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
>> nalezy do RIPE a nie ARINA. A w ARINIE tej route'y nie ma. Czy wobec tego
>> routa dla tego prefixu nie powinna być zarejestrowana w ARINIE zamiast w
>> RIPE?
>
> W internecie światowym bywają rozbieżności jeśli chodzi o to co jest
> rozgłaszane w BGP, a tym co jest opisane w bazach.

To że są rozbieżności to ja rozumiem zastanawiam się tylko jak należy 
traktować takie rejestrowanie w RIPE prefixu z przestrzeni adresowej 
ARINa. Tzn. czy jest to poprawne (z punktu widzenia typowego operatora, 
który filtruje ruch z niezarejestrowanych rout), jeśli nie to czemu wogóle 
RIPE pozawala na rejestrację u siebie nie swoich prefiksów, a jeśli tak to 
mimo wszystko jaki jest sens rejestracji w RIPE prefiksu który jest 
zarządzany przez innego RIRa.

Nawiasem mówiąc z tego co zauważyłem to w RIPE baza whois i route registry 
są ściśle powiązane a w ARINie ten sam prefix może być powiązany z jakimś 
ASem na http://whois.arin.net a sprawdzając przy pomocy whoisa ten sam 
prefix na rr.arin.net już takiego powiązania może nie być.

Zresztą nawet sami o tym piszą na https://www.arin.net/resources/routing/ 
"This database is separate from ARIN's registration database, which 
contains IP address and Autonomous System Number registration data, and is 
searchable using the Whois directory service."

Jak dla mnie cokolwiek dziwne podejście.

>> Przy okazji czy ktoś może zna providera (najlepiej konkretne IP), który
>> nie przyjmuje ruchu z prefixów do których nie ma zarejestrowanych rout
>> żeby to można było w praktyce przetestować np. pingiem że z prefiksów dla
>> których są zarejestrowane odpowiednie routy ruch jest przepuszczany a dla
>> takich dla których rejestracji nie ma albo jest niepoprawna ruch nie
>> będzie wpuszczony?
>
> Z polskich to np. TP / Orange (as5617 i as29535) lub Atman (as24748, as15694)
> Z Tier-1 napewno kiedyś filtrował Level3.

No dobra, a sorry za lamerskie pytanie, ale czy to filtrowanie dotyczy np. 
peeringu dla takich sieci dla których nie ma zarejestrowanych rout czy 
wogóle z takich prefiksów ruch nie jest wpuszczany do sieci operatora. 
Pytam, bo sprawdziłem np. traceroute na porcie 80 z 104.244.208.206 (nie 
wydaje się mieć zarejestrowanej routy) do 212.91.4.13 i wszystko jakby 
działa:

1       104.244.208.201         104.244.208.0/24        Coats North America (AS 13737)  < 1
2       173.225.191.65  c-173-225-191-65.troy1-mi.riverfrontcomm.net    173.225.176.0/20        ManagedWay (AS 53292)   < 1
3       173.225.176.92  core4.sff2.r256.net     173.225.176.0/20        ManagedWay (AS 53292)   8.1
4       4.31.123.97     vlan259.car1.Detroit1.Level3.net        4.31.122.0/23   Level 3 Communications, Inc. (AS 3356)  35.5
5       4.69.201.154    ae-2-3102.bar2.Budapest1.Level3.net     4.0.0.0/9       Level 3 Communications, Inc. (AS 3356)  108.9
6       212.162.26.138  dialup-212.162.26.138.frankfurt1.mik.net        212.162.0.0/18  Level 3 Communications, Inc. (AS 3356)  129
7       85.232.252.32   xe-5-1-0-4086.r1.isp-r5.isp.atman.pl    85.232.224.0/19 ATMAN (AS 15694)        129.7
8       212.91.4.13     host-212-91-4-13.itbcg.pl       212.91.4.0/22   ATMAN (AS 15694)        129.4
9       212.91.4.13     host-212-91-4-13.itbcg.pl       212.91.4.0/22   ATMAN (AS 15694)        129.4