Folks,
It is my belief that many ISPs, will not accept datagrams containing the
Router Alert IP option from customers. Do I have that right?
I am asking so that I might better evaluate Internet drafts that would
require ISPs to accept such packets.
Ron Bonica
Ron Bonica <rbonica@juniper.net> writes:
Folks,
It is my belief that many ISPs, will not accept datagrams containing the
Router Alert IP option from customers. Do I have that right?
I think that in general, it is safe to say that most folks who run
Internet backbones do not care what options you have on IP packets and
are not filtering anyway. Heck, I've never encountered anything
beyond unicast RPF in terms of SP filtering, and even *that* is not
especially prevalent. If he's reading, Dave Katz will probably be
disappointed to hear that I couldn't even remember what that option
did without referring to RFC2113.
I am asking so that I might better evaluate Internet drafts that would
require ISPs to accept such packets.
Do these drafts actually exist, or are they merely hypothetical?
---rob
What you're likely to find in *reality* is that ISPs will be more than happy
to pass the packets along, but the corporate/consumer firewalls in place
at the ISP's *customers* will stomp on the options (see all the ways that
mismanaged firewalls fail to do ingress/egress filtering of rfc1918 packets,
or think "ICMP Frag Needed" means "This ICMP needs to be fragged", or...).
And it doesn't really matter if it's the ISP or the end site that screws it
up - if it gets thrown away, it gets thrown away.
Unless you had an ISP-specific use for Router Alert, where end-customer
behavior doesn't matter?
Folks,
It is my belief that many ISPs, will not accept datagrams containing the
Router Alert IP option from customers. Do I have that right?I am asking so that I might better evaluate Internet drafts that would
require ISPs to accept such packets.What you're likely to find in *reality* is that ISPs will be more than happy
to pass the packets along, but the corporate/consumer firewalls in place
s/pass the packets/pass the packets that don't harm their network devices/
at the ISP's *customers* will stomp on the options (see all the ways that
mismanaged firewalls fail to do ingress/egress filtering of rfc1918 packets,
or think "ICMP Frag Needed" means "This ICMP needs to be fragged", or...).And it doesn't really matter if it's the ISP or the end site that screws it
up - if it gets thrown away, it gets thrown away.Unless you had an ISP-specific use for Router Alert, where end-customer
behavior doesn't matter?
router-alert is blocked in many places, I believe (I'm fuzzy on this)
that some vendors allow you to ignore router-alert, which I think is
the preferred option for this option.
-Chris
Depends on what you mean by the word "accept."
Transit backbone operators have been changing to the position of protecting their router CPU's from user packets being punted up the control plane.
If they can forward the packet without going up the control plane, I think
most transit backbones will "accept" the packet and ignore IP options like
Router Alert.
If someone writes a standard to require ISPs to do something besides ignore an IP option and forward the packet, then you may see ISPs drop packets instead of punting them to the control plane. For example, packets with IP Source Route options.
Router# conf t
Router(config)# ip options ignore
Router(config)# exit
Router# write mem
As Chris mentions, packets with IP options are likely to have more problems crossing firewalls/security devices or even simple NAT/middle-boxes.
I don't remember who, but someone once suggested if we could go back
in time to the late 1970's and redo the Internet Protocol we would
get rid of all IP options and made IP addresses 64 bits and classless
from the beginning.