Subject: [rrg] ILNP clarification

From: Ran Atkinson <[email-masked]>
Date: Mon, 19 Apr 2010 17:12:23 -0400

Folks,

  As I've said before, ILNP can work with IPv4 as well as IPv6.
Of course, the engineering varies, but the architecture is the same.
Folks might want to examine the L32 record in draft-rja-ilnp-dns,
for example.  

  Further, multiple ISP folk tell me that they are now 
configuring their routers to ignore all IPv4 options (including
the IPv4 Router Alert option) because of concerns about (D)DOS
attacks on backbone infrastructure.  

  This new deployment approach has the effect of making all deployed 
IPv4 options end-to-end options, rather than being hop-by-hop options.  
It also means that if one puts an IPv4 option in an IPv4 packet, 
it is likely to be received at the intended end node, and also is
likely NOT to cause performance issues in IPv4 backbones.

Cheers,
 
Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Apr 2010 09:26:08 +1200

On 2010-04-20 09:12, Ran Atkinson wrote:
> configuring their routers to ignore all IPv4 options 

Actually, draft-carpenter-aeiou (one of older proposals for
extending IPv4 addresses) was dropped in 1994 because of the issue
of the Internet not being transparent to new options. There's
really nothing new under the sun.

   Brian

(including
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: Fred Baker <[email-masked]>
Date: Mon, 19 Apr 2010 14:32:09 -0700

...and is likely to not perform its function if it is intended to be a hop-by-hop option...

> attacks on backbone infrastructure.  

I don't think that's especially new...

> likely NOT to cause performance issues in IPv4 backbones.

http://www.ipinc.net/IPv4.GIF

---

From: Ran Atkinson <[email-masked]>
Date: Mon, 19 Apr 2010 18:03:14 -0400

> ...and is likely to not perform its function if it is intended to be a hop-by-hop option...

I'm assuming the above began with:
	An IPv4 option ...

> I don't think that's especially new...

Thanks for the confirmation.

Your comment seems to confirm the notion that an IPv4 option might well
be deployed *provided* it is intended to be an end-to-end option.

Yours,

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Apr 2010 10:40:27 +1200

> be deployed *provided* it is intended to be an end-to-end option.

Yes, but *my* rather confusing reply should really have said that
although details have certainly changed since 1994, we still don't
*know* whether a newly defined IPv4 option will or will not survive
a trip across the Internet on any particular path.

(Thanks to Joel and Ran for pointing out in private mail the extent to
which my message was confused.)

    Brian

---

From: Ran Atkinson <[email-masked]>
Date: Mon, 19 Apr 2010 19:36:19 -0400

> a trip across the Internet on any particular path.

I don't *know* whether any of my packets will survive a trip
across the Internet.  Earlier today, the probability of a 
packet leaving my site (or entering it) was close to zero.
Right now, the probability is vastly closer to 1, but it is
certainly not equal to 1.

ISP folks are telling me that the presence of IPv4 options
is *ignored* by the IP backbone routers.  Put in other words,
IPv4 packets containing options *are* delivered across the
backbone -- they aren't dropped by the backbone router and
they aren't slow-path forwarded by the backbone router.

So as near as one can tell, what has happened is that all 
IPv4 options are "end-to-end options" -- at least within 
the backbone.

The real issue is probably security gateways.  At least some
security gateways have configurable options whether to look
at (some) IPv4 options and to make some set of decisions about
packet handling based on those options.  [For an example, see
RFC-1108 which is more widely deployed today than 20 years ago,
by the way.]  The good thing about security gateways is that
they are deployed by end sites.  This means the end site has
control over the security gateway configuration, and that 
means that new protocols (e.g. SIP) and other new technologies
(e.g. an IPv4 option) can be deployed if the site finds it
desirable to do so.

Cheers,

Ran

---

From: Xiaoliang Zhao <[email-masked]>
Date: Tue, 20 Apr 2010 10:03:05 +0800

> is *ignored* by the IP backbone routers.  Put in other words,

As far as I know, backbone routers at least response to Router Alert
option because RSVP is uing it.

Best,
Leon

---

From: Eliot Lear <[email-masked]>
Date: Tue, 20 Apr 2010 07:52:07 +0200

This seems to be an opportunity for data collection and analysis.  
Perhaps one of several next steps?

---

From: Ran Atkinson <[email-masked]>
Date: Tue, 20 Apr 2010 07:50:01 -0400

> option because RSVP is uing it.

A number of ISP folks tell me that while backbone routers *can*
be configured to respond differently to IPv4 packets containing
options (e.g. Router Alert), their backbone routers have been 
configured to NOT do that, and instead to ignore all IPv4 options.

RSVP is not widely deployed for per-flow QoS, and never has been.  
An obvious question would be whether LDP is more widely deployed
than RSVP (e.g. in an MPLS context).  I don't have any data on 
relative use of LDP vs RSVP for MPLS signalling.

Yours,

Ran

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 20 Apr 2010 14:16:03 +0200 (CEST)

On Tue, 20 Apr 2010, Ran Atkinson wrote:

> RSVP is not widely deployed for per-flow QoS, and never has been. An 
> obvious question would be whether LDP is more widely deployed than RSVP 
> (e.g. in an MPLS context).  I don't have any data on relative use of LDP 
> vs RSVP for MPLS signalling.

They are both in widespread use so neither can be ignored.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Tue, 20 Apr 2010 15:16:12 +0300 (EEST)

> configured to NOT do that, and instead to ignore all IPv4 options.

Just out of curiousity, how do you configure a Juniper and Cisco 
router to do that?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Xiaoliang Zhao <[email-masked]>
Date: Wed, 21 Apr 2010 09:24:34 +0800

>> (e.g. in an MPLS context).  I don't have any data on relative use of LDP vs
>> RSVP for MPLS signalling.
>
That's right. My previous company, a tier-1 ISP with world-wide
presence, heavily depend on RSVP/MPLS to do traffic engineering. LDP
is also used but more deployed to extend MPLS LSP to the edge, it's
mainly because LDP is simpler to config but cannot do TE.

Best,
Leon