Routing packets to RFC1918 address over internet - Networking

This is a discussion on Routing packets to RFC1918 address over internet - Networking ; -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've recently experienced this issue with VSNL, an Indian ISP. I've an internet connection from them, I recently noticed this: - ---->8---->8---- edmond@monte-cristo:~$ traceroute -I msdn.microsoft.com traceroute to msdn.microsoft.akadns.net (65.55.11.235), 30 hops max, ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Routing packets to RFC1918 address over internet

  1. Routing packets to RFC1918 address over internet

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Hi,

    I've recently experienced this issue with VSNL, an Indian ISP. I've an
    internet connection from them, I recently noticed this:

    - ---->8---->8----
    edmond@monte-cristo:~$ traceroute -I msdn.microsoft.com
    traceroute to msdn.microsoft.akadns.net (65.55.11.235), 30 hops max,
    52 byte packets
    1 210.211.168.1.bb-static.vsnl.net.in (210.211.168.1) 26.749 ms
    27.256 ms 27.091 ms
    2 delhi-203.200.108-213.vsnl.net.in (203.200.108.213) 26.836 ms
    27.022 ms 26.588 ms
    3 59.163.16.138.static.vsnl.net.in (59.163.16.13 8) 294.918 ms
    294.162 ms 295.428 ms
    4 219.64.231.5.mpls-vpn-sj.static.vsnl.net.in (219.64.231.5)
    299.259 ms 299.098 ms 298.917 ms
    5 ge-6-3-0-46.pao-64cb-1b.ntwk.msn.net (207.46.46.67) 298.534 ms
    299.173 ms 297.798 ms
    6 ge-1-2-0-0.tuk-64cb-1b.ntwk.msn.net (207.46.33.222) 312.887 ms
    313.286 ms 313.417 ms
    7 ge-3-0-0-0.co1-64c-1b.ntwk.msn.net (207.46.34.41) 316.248 ms
    317.286 ms 316.995 ms
    8 ge-0-0-0-0.co1-64c-1a.ntwk.msn.net (207.46.34.189) 321.016 ms
    320.803 ms 320.532 ms
    9 10.22.8.62 (10.22.8.62) 321.021 ms 319.924 ms 319.659 ms
    10 * * *
    11 * * *
    12 * * *
    13 * * *
    14 * * *
    - ---->8---->8----

    I'm a n00b in routing, esp. never configured any EGRP protcol
    implementation, so I wanted to know how is MSN being able to send a
    packet from an RFC1918 address to VSNL's network. I expect packets
    destined to RFC1918 address to be dropped at site-level (or
    organization-level) routers, but this is border-level. And following is
    the traceroute to the same from another Indian ISP (Airtel), which
    relies on Sprint to reach MSN.

    - ---->8---->8----
    abbe [~] chateau% sudo traceroute -I msdn.microsoft.com
    Password:
    traceroute to msdn.microsoft.akadns.net (65.55.11.235), 64 hops max, 72 byte packets
    1 * * *
    2 ABTS-NCR-Static-246.220.160.122.airtelbroadband.in (122.160.220.246) 33.458 ms 29.046 ms 30.290 ms
    3 rasBTNLDel-static-174.215.56.202.mantraonline.com (202.56.215.174) 33.563 ms 31.811 ms 30.377 ms
    4 125.19.22.145 (125.19.22.145) 29.517 ms 28.377 ms 30.774 ms
    5 125.21.167.25 (125.21.167.25) 75.891 ms 75.737 ms 75.602 ms
    6 sl-gw39-nyc-10-1.sprintlink.net (160.81.228.73) 294.580 ms 301.473 ms306.050 ms
    7 sl-bb21-nyc-3-0-0.sprintlink.net (144.232.13.57) 297.558 ms 297.729 ms 299.510 ms
    8 sl-bb22-nyc-14-0.sprintlink.net (144.232.7.102) 304.510 ms 314.244 ms305.923 ms
    9 sl-bb21-chi-3-0-0.sprintlink.net (144.232.20.102) 332.567 ms 331.458 ms 331.284 ms
    10 sl-bb25-chi-13-0.sprintlink.net (144.232.26.90) 328.455 ms 328.153 ms360.344 ms
    11 sl-bb20-sea-1-0.sprintlink.net (144.232.20.85) 370.266 ms 367.872 ms 369.547 ms
    12 sl-gw20-sea-0-0-0.sprintlink.net (144.232.6. 8) 375.711 ms 406.419 ms378.141 ms
    13 sl-microsoft-23-0.sprintlink.net (144.224.113.146) 384.781 ms 383.371ms 387.322 ms
    14 207.46.41.125 (207.46.41.125) 401.802 ms 402.980 ms 415.847 ms
    15 ge-3-0-0-0.co1-64c-1b.ntwk.msn.net (207.46.34.41) 388.315 ms 549.512 ms *
    16 ge-0-0-0-0.co1-64c-1a.ntwk.msn.net (207.46.34.189) 390.412 ms 416.519ms 386.261 ms
    17 * * *
    18 * * *
    19 * * *
    20 * * *
    - ---->8---->8----

    Is such behavior expected from ISPs ?

    TIA for enlightening me.
    - --
    Ashish Shukla आशीष शुक्ल http://wahjava.wordpress.com/
    ·-- ·- ···· ·--- ·- ···- ·- ·--·-· --· -- ·- ·· ·-·· ·-·-·- -·-· --- --
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.9 (FreeBSD)

    iEYEARECAAYFAkhml5kACgkQHy+EEHYuXnQQOACfVbUBO2/tX2mDWczn7MY4bNhS
    S7wAn3c104vR60MZa+Qp0SxqxWrFrIfJ
    =UWsS
    -----END PGP SIGNATURE-----

  2. Re: Routing packets to RFC1918 address over internet

    Ashish Shukla आशीष शुक्ल wrote:
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > Hi,
    >
    > I've recently experienced this issue with VSNL, an Indian ISP. I've an
    > internet connection from them, I recently noticed this:
    >
    > - ---->8---->8----
    > edmond@monte-cristo:~$ traceroute -I msdn.microsoft.com
    > traceroute to msdn.microsoft.akadns.net (65.55.11.235), 30 hops max,
    > 52 byte packets
    > 1 210.211.168.1.bb-static.vsnl.net.in (210.211.168.1) 26.749 ms
    > 27.256 ms 27.091 ms
    > 2 delhi-203.200.108-213.vsnl.net.in (203.200.108.213) 26.836 ms
    > 27.022 ms 26.588 ms
    > 3 59.163.16.138.static.vsnl.net.in (59.163.16.13 8) 294.918 ms
    > 294.162 ms 295.428 ms
    > 4 219.64.231.5.mpls-vpn-sj.static.vsnl.net.in (219.64.231.5)
    > 299.259 ms 299.098 ms 298.917 ms
    > 5 ge-6-3-0-46.pao-64cb-1b.ntwk.msn.net (207.46.46.67) 298.534 ms
    > 299.173 ms 297.798 ms
    > 6 ge-1-2-0-0.tuk-64cb-1b.ntwk.msn.net (207.46.33.222) 312.887 ms
    > 313.286 ms 313.417 ms
    > 7 ge-3-0-0-0.co1-64c-1b.ntwk.msn.net (207.46.34.41) 316.248 ms
    > 317.286 ms 316.995 ms
    > 8 ge-0-0-0-0.co1-64c-1a.ntwk.msn.net (207.46.34.189) 321.016 ms
    > 320.803 ms 320.532 ms
    > 9 10.22.8.62 (10.22.8.62) 321.021 ms 319.924 ms 319.659 ms
    > 10 * * *
    > 11 * * *
    > 12 * * *
    > 13 * * *
    > 14 * * *
    > - ---->8---->8----
    >
    > I'm a n00b in routing, esp. never configured any EGRP protcol
    > implementation, so I wanted to know how is MSN being able to send a
    > packet from an RFC1918 address to VSNL's network. I expect packets
    > destined to RFC1918 address to be dropped at site-level (or
    > organization-level) routers, but this is border-level. And following is
    > the traceroute to the same from another Indian ISP (Airtel), which
    > relies on Sprint to reach MSN.



    The ISP's are free to use the RFC 1918 addresses in their network,
    as long as they are kept inside their own network. The same applies
    to anybody wishing to use them.

    A different story is if you want to connect two RFC 1918 segments
    at separate locations so they see each other. Here, the solution
    is tunneling, often implemented as a Virtual Private Network (VPN).

    --

    -Tauno Voipio

  3. Re: Routing packets to RFC1918 address over internet

    On Sun, 29 Jun 2008 01:26:59 +0530, Ashish Shukla आशीष श
    ुक्ल wrote:

    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > Hi,
    >
    > I've recently experienced this issue with VSNL, an Indian ISP. I've an
    > internet connection from them, I recently noticed this:
    >
    > - ---->8---->8----
    > edmond@monte-cristo:~$ traceroute -I msdn.microsoft.com traceroute to
    > msdn.microsoft.akadns.net (65.55.11.235), 30 hops max, 52 byte packets
    > 1 210.211.168.1.bb-static.vsnl.net.in (210.211.168.1) 26.749 ms
    > 27.256 ms 27.091 ms
    > 2 delhi-203.200.108-213.vsnl.net.in (203.200.108.213) 26.836 ms
    > 27.022 ms 26.588 ms
    > 3 59.163.16.138.static.vsnl.net.in (59.163.16.13 8) 294.918 ms
    > 294.162 ms 295.428 ms
    > 4 219.64.231.5.mpls-vpn-sj.static.vsnl.net.in (219.64.231.5)
    > 299.259 ms 299.098 ms 298.917 ms
    > 5 ge-6-3-0-46.pao-64cb-1b.ntwk.msn.net (207.46.46.67) 298.534 ms
    > 299.173 ms 297.798 ms
    > 6 ge-1-2-0-0.tuk-64cb-1b.ntwk.msn.net (207.46.33.222) 312.887 ms
    > 313.286 ms 313.417 ms
    > 7 ge-3-0-0-0.co1-64c-1b.ntwk.msn.net (207.46.34.41) 316.248 ms
    > 317.286 ms 316.995 ms
    > 8 ge-0-0-0-0.co1-64c-1a.ntwk.msn.net (207.46.34.189) 321.016 ms
    > 320.803 ms 320.532 ms
    > 9 10.22.8.62 (10.22.8.62) 321.021 ms 319.924 ms 319.659 ms
    > 10 * * *
    > 11 * * *
    > 12 * * *
    > 13 * * *
    > 14 * * *
    > - ---->8---->8----
    >
    > I'm a n00b in routing, esp. never configured any EGRP protcol
    > implementation, so I wanted to know how is MSN being able to send a
    > packet from an RFC1918 address to VSNL's network. I expect packets
    > destined to RFC1918 address to be dropped at site-level (or
    > organization-level) routers, but this is border-level. And following is
    > the traceroute to the same from another Indian ISP (Airtel), which
    > relies on Sprint to reach MSN.


    What you have to understand is that routing takes place on the
    destination address. In this case, the TTL exceeded packages that are
    sent back to you. These have your public IPA as the destination address
    so these do arrive.

    Whatever internal addressing someone uses is irrelevant. Some links in
    between you and the destination may use RFC1918 addresses to reach each
    other. As long as the target has a public IP address and all hops along
    the path know how to get the packet one hop closer to the destination,
    that's cool. It's how IP works. You normally never notice this, unless
    you do a traceroute.

    I the case of a traceroute, all routers along the path will send back
    eventually a TTL exceeded message (packet). This message is addressed to
    you, so it arrives. The router chooses some source address, normally the
    address of the interface the TTL-exceeded packet goes out on, or the IP
    address of the interface your original packet came in on, I'm not sure
    which one (more often than not, these are the same).

    So you get a packet addressed to you from some IP address. In normal
    communication the source address matters. It tells your machine (together
    with some other ID, like a tcp or udp port, or an icmp ID, which
    conversation this packet is a part of. In this case, the source address
    just tells you which router along the way dropped your packet. And if
    that router happens to be part of a link that uses RFC1918 addresses, you
    see RFC1918 addresses.

    HTH,
    M4

  4. Re: Routing packets to RFC1918 address over internet

    I don't think ISPs should do this, but have seen this. Years ago, I noticed
    that my ISP (a small local ISP) was tying together their POPs this way.
    Others may comment and I respect their opinion. I have not worked for an
    ISP but discourage this practice. My complaint is that unreachables coming
    from those addresses would be dropped at a properly configured border
    router. This breaks traceroute and PMTUD. PMTUD is definitely a big deal
    if the MTU is throttled. Hopefully the MTU in that area of the network is
    at least as large as the MTU on ethernet.

    "Ashish Shukla "???? ?" "????"" wrote in message
    news:86bq1l72pg.fsf@chateau.d.lf...
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Hi,

    I've recently experienced this issue with VSNL, an Indian ISP. I've an
    internet connection from them, I recently noticed this:

    - ---->8---->8----
    edmond@monte-cristo:~$ traceroute -I msdn.microsoft.com
    traceroute to msdn.microsoft.akadns.net (65.55.11.235), 30 hops max,
    52 byte packets
    1 210.211.168.1.bb-static.vsnl.net.in (210.211.168.1) 26.749 ms
    27.256 ms 27.091 ms
    2 delhi-203.200.108-213.vsnl.net.in (203.200.108.213) 26.836 ms
    27.022 ms 26.588 ms
    3 59.163.16.138.static.vsnl.net.in (59.163.16.13 8) 294.918 ms
    294.162 ms 295.428 ms
    4 219.64.231.5.mpls-vpn-sj.static.vsnl.net.in (219.64.231.5)
    299.259 ms 299.098 ms 298.917 ms
    5 ge-6-3-0-46.pao-64cb-1b.ntwk.msn.net (207.46.46.67) 298.534 ms
    299.173 ms 297.798 ms
    6 ge-1-2-0-0.tuk-64cb-1b.ntwk.msn.net (207.46.33.222) 312.887 ms
    313.286 ms 313.417 ms
    7 ge-3-0-0-0.co1-64c-1b.ntwk.msn.net (207.46.34.41) 316.248 ms
    317.286 ms 316.995 ms
    8 ge-0-0-0-0.co1-64c-1a.ntwk.msn.net (207.46.34.189) 321.016 ms
    320.803 ms 320.532 ms
    9 10.22.8.62 (10.22.8.62) 321.021 ms 319.924 ms 319.659 ms
    10 * * *
    11 * * *
    12 * * *
    13 * * *
    14 * * *
    - ---->8---->8----

    I'm a n00b in routing, esp. never configured any EGRP protcol
    implementation, so I wanted to know how is MSN being able to send a
    packet from an RFC1918 address to VSNL's network. I expect packets
    destined to RFC1918 address to be dropped at site-level (or
    organization-level) routers, but this is border-level. And following is
    the traceroute to the same from another Indian ISP (Airtel), which
    relies on Sprint to reach MSN.

    - ---->8---->8----
    abbe [~] chateau% sudo traceroute -I msdn.microsoft.com
    Password:
    traceroute to msdn.microsoft.akadns.net (65.55.11.235), 64 hops max, 72 byte
    packets
    1 * * *
    2 ABTS-NCR-Static-246.220.160.122.airtelbroadband.in (122.160.220.246)
    33.458 ms 29.046 ms 30.290 ms
    3 rasBTNLDel-static-174.215.56.202.mantraonline.com (202.56.215.174)
    33.563 ms 31.811 ms 30.377 ms
    4 125.19.22.145 (125.19.22.145) 29.517 ms 28.377 ms 30.774 ms
    5 125.21.167.25 (125.21.167.25) 75.891 ms 75.737 ms 75.602 ms
    6 sl-gw39-nyc-10-1.sprintlink.net (160.81.228.73) 294.580 ms 301.473 ms
    306.050 ms
    7 sl-bb21-nyc-3-0-0.sprintlink.net (144.232.13.57) 297.558 ms 297.729 ms
    299.510 ms
    8 sl-bb22-nyc-14-0.sprintlink.net (144.232.7.102) 304.510 ms 314.244 ms
    305.923 ms
    9 sl-bb21-chi-3-0-0.sprintlink.net (144.232.20.102) 332.567 ms 331.458
    ms 331.284 ms
    10 sl-bb25-chi-13-0.sprintlink.net (144.232.26.90) 328.455 ms 328.153 ms
    360.344 ms
    11 sl-bb20-sea-1-0.sprintlink.net (144.232.20.85) 370.266 ms 367.872 ms
    369.547 ms
    12 sl-gw20-sea-0-0-0.sprintlink.net (144.232.6. 8) 375.711 ms 406.419 ms
    378.141 ms
    13 sl-microsoft-23-0.sprintlink.net (144.224.113.146) 384.781 ms 383.371
    ms 387.322 ms
    14 207.46.41.125 (207.46.41.125) 401.802 ms 402.980 ms 415.847 ms
    15 ge-3-0-0-0.co1-64c-1b.ntwk.msn.net (207.46.34.41) 388.315 ms 549.512
    ms *
    16 ge-0-0-0-0.co1-64c-1a.ntwk.msn.net (207.46.34.189) 390.412 ms 416.519
    ms 386.261 ms
    17 * * *
    18 * * *
    19 * * *
    20 * * *
    - ---->8---->8----

    Is such behavior expected from ISPs ?

    TIA for enlightening me.
    - --
    Ashish Shukla ???? ????? http://wahjava.wordpress.com/
    -- - --- - - - --- -- -- - - --- -- --- --
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.9 (FreeBSD)

    iEYEARECAAYFAkhml5kACgkQHy+EEHYuXnQQOACfVbUBO2/tX2mDWczn7MY4bNhS
    S7wAn3c104vR60MZa+Qp0SxqxWrFrIfJ
    =UWsS
    -----END PGP SIGNATURE-----



  5. Re: Routing packets to RFC1918 address over internet

    Hello,

    Martijn Lievaart a crit :
    >
    > What you have to understand is that routing takes place on the
    > destination address. [...]


    This is all nice, but RFC 3330 states about the three private blocks :
    Addresses within this block should not appear on the public Internet

    And RFC 1918 states :
    Because private addresses have no global meaning, routing information
    about private networks shall not be propagated on inter-enterprise
    links, and packets with private source or destination addresses
    should not be forwarded across such links.

    A "should" requirement may be ignored if and only if there is a very
    good reason to do so. What may be the good reason to send traffic with a
    private address to a destination on another network ? I do not believe
    that ISP's and carriers suffer from public address shortage.

  6. Re: Routing packets to RFC1918 address over internet

    "Pascal Hambourg" wrote in message
    news:g46f2o$2h1o$1@biggoron.nerim.net...
    > Martijn Lievaart a crit :
    > > What you have to understand is that routing takes place on the
    > > destination address. [...]

    >
    > This is all nice, but RFC 3330 states about the three private blocks :
    > Addresses within this block should not appear on the public Internet
    >
    > And RFC 1918 states :
    > Because private addresses have no global meaning, routing information
    > about private networks shall not be propagated on inter-enterprise
    > links, and packets with private source or destination addresses
    > should not be forwarded across such links.
    >
    > A "should" requirement may be ignored if and only if there is a very
    > good reason to do so. What may be the good reason to send traffic with a
    > private address to a destination on another network ? I do not believe
    > that ISP's and carriers suffer from public address shortage.


    Internally, they're using 10.0.0.0/8, but what you might not be seeing is
    the Network Address Translation (NAT) being done at their border router as
    the packets cross into and from their network to/from the Internet.

    The border router is at IPv4 address 207.46.34.189.

    Aside, you expect Micro$oft to follow the rules of the Internet? They often
    don't.



  7. Re: Routing packets to RFC1918 address over internet

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    ,--- D Stussy writes:
    | "Pascal Hambourg" wrote in message
    | news:g46f2o$2h1o$1@biggoron.nerim.net...
    || Martijn Lievaart a crit :
    || > What you have to understand is that routing takes place on the
    || > destination address. [...]
    ||
    || This is all nice, but RFC 3330 states about the three private blocks :
    || Addresses within this block should not appear on the public Internet
    ||
    || And RFC 1918 states :
    || Because private addresses have no global meaning, routing information
    || about private networks shall not be propagated on inter-enterprise
    || links, and packets with private source or destination addresses
    || should not be forwarded across such links.
    ||
    || A "should" requirement may be ignored if and only if there is a very
    || good reason to do so. What may be the good reason to send traffic with a
    || private address to a destination on another network ? I do not believe
    || that ISP's and carriers suffer from public address shortage.

    | Internally, they're using 10.0.0.0/8, but what you might not be seeing is
    | the Network Address Translation (NAT) being done at their border router as
    | the packets cross into and from their network to/from the Internet.

    Where is the NAT ? If it is NAT, I don't think I'll be able to see their
    internal address. It is simply packet forwarding between interfaces.

    | The border router is at IPv4 address 207.46.34.189.

    Or it is, 207.46.46.67 ?

    Thanks all for the replies.
    - --
    -- - --- - - - --- -- -- - - --- -- --- --
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.9 (GNU/Linux)

    iEYEARECAAYFAkhnDbEACgkQHy+EEHYuXnREVQCff5SGuTwohR JZLhAJdJNpKDdR
    8ZoAn2LA1EqecE892bTGGyLwbKNWGzxe
    =/jHP
    -----END PGP SIGNATURE-----

  8. Re: Routing packets to RFC1918 address over internet

    In article <86bq1l72pg.fsf@chateau.d.lf>,
    wahjava@gmail.com (Ashish Shukla ???? ?????) wrote:

    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > Hi,
    >
    > I've recently experienced this issue with VSNL, an Indian ISP. I've an
    > internet connection from them, I recently noticed this:
    >
    > - ---->8---->8----
    > edmond@monte-cristo:~$ traceroute -I msdn.microsoft.com
    > traceroute to msdn.microsoft.akadns.net (65.55.11.235), 30 hops max,
    > 52 byte packets
    > 1 210.211.168.1.bb-static.vsnl.net.in (210.211.168.1) 26.749 ms
    > 27.256 ms 27.091 ms
    > 2 delhi-203.200.108-213.vsnl.net.in (203.200.108.213) 26.836 ms
    > 27.022 ms 26.588 ms
    > 3 59.163.16.138.static.vsnl.net.in (59.163.16.13 8) 294.918 ms
    > 294.162 ms 295.428 ms
    > 4 219.64.231.5.mpls-vpn-sj.static.vsnl.net.in (219.64.231.5)
    > 299.259 ms 299.098 ms 298.917 ms
    > 5 ge-6-3-0-46.pao-64cb-1b.ntwk.msn.net (207.46.46.67) 298.534 ms
    > 299.173 ms 297.798 ms
    > 6 ge-1-2-0-0.tuk-64cb-1b.ntwk.msn.net (207.46.33.222) 312.887 ms
    > 313.286 ms 313.417 ms
    > 7 ge-3-0-0-0.co1-64c-1b.ntwk.msn.net (207.46.34.41) 316.248 ms
    > 317.286 ms 316.995 ms
    > 8 ge-0-0-0-0.co1-64c-1a.ntwk.msn.net (207.46.34.189) 321.016 ms
    > 320.803 ms 320.532 ms
    > 9 10.22.8.62 (10.22.8.62) 321.021 ms 319.924 ms 319.659 ms
    > 10 * * *
    > 11 * * *
    > 12 * * *
    > 13 * * *
    > 14 * * *
    > - ---->8---->8----
    >
    > I'm a n00b in routing, esp. never configured any EGRP protcol
    > implementation, so I wanted to know how is MSN being able to send a
    > packet from an RFC1918 address to VSNL's network. I expect packets
    > destined to RFC1918 address to be dropped at site-level (or
    > organization-level) routers, but this is border-level. And following is


    Correct, you can't send packets TO RFC 1918 addresses. But traceroute
    is showing packets FROM those addresses.

    > the traceroute to the same from another Indian ISP (Airtel), which
    > relies on Sprint to reach MSN.


    Either Airtel or Sprint has a filter that drops packets with RFC 1918
    source addresses.

    >
    > - ---->8---->8----
    > abbe [~] chateau% sudo traceroute -I msdn.microsoft.com
    > Password:
    > traceroute to msdn.microsoft.akadns.net (65.55.11.235), 64 hops max, 72 byte
    > packets
    > 1 * * *
    > 2 ABTS-NCR-Static-246.220.160.122.airtelbroadband.in (122.160.220.246)
    > 33.458 ms 29.046 ms 30.290 ms
    > 3 rasBTNLDel-static-174.215.56.202.mantraonline.com (202.56.215.174)
    > 33.563 ms 31.811 ms 30.377 ms
    > 4 125.19.22.145 (125.19.22.145) 29.517 ms 28.377 ms 30.774 ms
    > 5 125.21.167.25 (125.21.167.25) 75.891 ms 75.737 ms 75.602 ms
    > 6 sl-gw39-nyc-10-1.sprintlink.net (160.81.228.73) 294.580 ms 301.473 ms
    > 306.050 ms
    > 7 sl-bb21-nyc-3-0-0.sprintlink.net (144.232.13.57) 297.558 ms 297.729 ms
    > 299.510 ms
    > 8 sl-bb22-nyc-14-0.sprintlink.net (144.232.7.102) 304.510 ms 314.244 ms
    > 305.923 ms
    > 9 sl-bb21-chi-3-0-0.sprintlink.net (144.232.20.102) 332.567 ms 331.458 ms
    > 331.284 ms
    > 10 sl-bb25-chi-13-0.sprintlink.net (144.232.26.90) 328.455 ms 328.153 ms
    > 360.344 ms
    > 11 sl-bb20-sea-1-0.sprintlink.net (144.232.20.85) 370.266 ms 367.872 ms
    > 369.547 ms
    > 12 sl-gw20-sea-0-0-0.sprintlink.net (144.232.6. 8) 375.711 ms 406.419 ms
    > 378.141 ms
    > 13 sl-microsoft-23-0.sprintlink.net (144.224.113.146) 384.781 ms 383.371
    > ms 387.322 ms
    > 14 207.46.41.125 (207.46.41.125) 401.802 ms 402.980 ms 415.847 ms
    > 15 ge-3-0-0-0.co1-64c-1b.ntwk.msn.net (207.46.34.41) 388.315 ms 549.512 ms
    > *
    > 16 ge-0-0-0-0.co1-64c-1a.ntwk.msn.net (207.46.34.189) 390.412 ms 416.519
    > ms 386.261 ms
    > 17 * * *
    > 18 * * *
    > 19 * * *
    > 20 * * *
    > - ---->8---->8----
    >
    > Is such behavior expected from ISPs ?
    >
    > TIA for enlightening me.
    > - --
    > Ashish Shukla ???? ????? http://wahjava.wordpress.com/
    > ·-- ·- ···· ·--- ·- ···- ·- ·--·-· --· -- ·- ·· ·-·· ·-·-·- -·-· --- --
    > -----BEGIN PGP SIGNATURE-----
    > Version: GnuPG v2.0.9 (FreeBSD)
    >
    > iEYEARECAAYFAkhml5kACgkQHy+EEHYuXnQQOACfVbUBO2/tX2mDWczn7MY4bNhS
    > S7wAn3c104vR60MZa+Qp0SxqxWrFrIfJ
    > =UWsS
    > -----END PGP SIGNATURE-----


    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  9. Re: Routing packets to RFC1918 address over internet

    ,--[ On Sun, Jun 29, 2008 at 02:04:41AM -0400, Barry Margolin wrote:
    | In article <86bq1l72pg.fsf@chateau.d.lf>,
    | wahjava@gmail.com (Ashish Shukla ???? ?????) wrote:

    [snip]

    | > I'm a n00b in routing, esp. never configured any EGRP protcol
    | > implementation, so I wanted to know how is MSN being able to send a
    | > packet from an RFC1918 address to VSNL's network. I expect packets
    | > destined to RFC1918 address to be dropped at site-level (or
    | > organization-level) routers, but this is border-level. And following is
    |
    | Correct, you can't send packets TO RFC 1918 addresses. But traceroute
    | is showing packets FROM those addresses.
    |
    | > the traceroute to the same from another Indian ISP (Airtel), which
    | > relies on Sprint to reach MSN.
    |
    | Either Airtel or Sprint has a filter that drops packets with RFC 1918
    | source addresses.

    So this is what one should expect from a top-level internet host, right ?

    Thanks
    --
    ·-- ·- ···· ·--- ·- ···- ·- ·--·-· --· -- ·- ·· ·-·· ·-·-·- -·-· --- --

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.9 (FreeBSD)

    iEYEARECAAYFAkhna5sACgkQHy+EEHYuXnQO/wCdHIAQUWStUvL+C0JRT802aIja
    sRoAoKYTkkN9Bzz7F1jLwH1YXYuxpL2P
    =Z/yW
    -----END PGP SIGNATURE-----


  10. Re: Routing packets to RFC1918 address over internet

    On Sun, 29 Jun 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article , Pascal Hambourg wrote:

    >Martijn Lievaart a crit :
    >
    >> What you have to understand is that routing takes place on the
    >> destination address. [...]

    >
    >This is all nice, but RFC 3330 states about the three private blocks :
    > Addresses within this block should not appear on the public Internet


    3330 Special-Use IPv4 Addresses. IANA. September 2002. (Format:
    TXT=16200 bytes) (Status: INFORMATIONAL)

    You may want to read RFC2026, and understand what the "Status:" term
    means. Then compare the statements in RFC1122 and RFC1812.

    1122 Requirements for Internet Hosts - Communication Layers. R.
    Braden, Ed.. October 1989. (Format: TXT=295992 bytes) (Updated
    by RFC1349, RFC4379) (Also STD0003) (Status: STANDARD)

    1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995.
    (Format: TXT=415740 bytes) (Obsoletes RFC1716, RFC1009) (Updated
    by RFC2644) (Status: PROPOSED STANDARD)

    You should also read the "Status of this Memo" section on the first page
    of RFC3330, specifically the second sentence.

    >And RFC 1918 states :
    > Because private addresses have no global meaning, routing information
    > about private networks shall not be propagated on inter-enterprise
    > links, and packets with private source or destination addresses
    > should not be forwarded across such links.


    1918 Address Allocation for Private Internets. Y. Rekhter, B.
    Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February 1996.
    (Format: TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Also
    BCP0005) (Status: BEST CURRENT PRACTICE)

    Again, see RFC2026.

    >A "should" requirement may be ignored if and only if there is a very
    >good reason to do so. What may be the good reason to send traffic with
    >a private address to a destination on another network ? I do not believe
    >that ISP's and carriers suffer from public address shortage.


    There is no need to _waste_ a perfectly useful routable address when
    sending ICMP error messages from systems that the public has no need
    to access. Most providers see no reason to allow the public to connect
    to routers, firewalls, and the like. Do you think otherwise?

    As far as the shortage of public addresses, you should note what the
    RIRs are now handing out as assignments and allocations. While IPv6 land
    is rather unpopulated (about 0.0135 percent of non-RFC5156 space), IPv4
    land is getting rather crowded (71.79 percent of non-RFC3330 space). Both
    figures are from 15 June 2008.

    Old guy

  11. Re: Routing packets to RFC1918 address over internet

    On Sun, 29 Jun 2008 16:31:50 +0530, आशीष शुक्ल Ashish Shukla wrote:

    > So this is what one should expect from a top-level internet host, right
    > ?


    Packets with "unroutable" addresses should be dropped at border routers
    whether those are source or destination addresses. I can see the
    motivation for choosing to let packets with unroutable source addresses
    through: they can be usefully informative w/o wasting public address
    space on internal infrastructure.

    But those packets also become untraceable back to their source after a
    few hops, which can be a bad thing.

    I'd worry more, though, about a failure to filter out routable but
    impossible addresses. A network shouldn't let a packet out if that
    packet has a source address not correct for that network. Or, for that
    matter, routers shouldn't accept incorrect route announcements. That's
    how some ISP in Pakistan was able to shut down youtube for a while, for
    example.

    - Andrew

+ Reply to Thread