-----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-----

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

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

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 "???? ?" "????"" <wahjava@gmail.com> 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-----

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.

"Pascal Hambourg" <boite-a-spam@plouf.fr.eu.org> 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.

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

,--- D Stussy writes:
| "Pascal Hambourg" <boite-a-spam@plouf.fr.eu.org> 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-----

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 ***

,--[ 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-----

On Sun, 29 Jun 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <g46f2o$2h1o$1@biggoron.nerim.net>, 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