Subject: Router redirects in Node Requirements document

From: Alain Durand <[email-masked]>
Date: Thu, 12 Aug 2010 12:47:16 -0700

I have a question about draft-ietf-6man-node-req-bis-05.txt.
Section 5.2:

   Redirect functionality SHOULD be supported.  If the node is a router,
   Redirect functionality MUST be supported.

However, draft-ietf-6man-node-req-bis-05.txt refer to the normative text on Neighbor Discovery, ie RFC4861 that says:
Section 8.2:

 A router SHOULD send a redirect message, subject to rate limiting,
   whenever it forwards a packet that is not explicitly addressed to
   itself (i.e., a packet that is not source routed through the router)
   in which:

      - the Source Address field of the packet identifies a neighbor,
        and

      - the router determines (by means outside the scope of this
        specification) that a better first-hop node resides on the same
        link as the sending node for the Destination Address of the
        packet being forwarded, and

      - the Destination Address of the packet is not a multicast
        address.

It seems that the Node requirement text is going above and beyond what is required by RFC4861, transforming the SHOULD into a MUST.
I might have missed (or do not remember) the discussion, is there a reason for this change? And shouldn't the ND spec have been changed first
to allow to upgrade the SHOULD into A MUST?

For the record, I support the SHOULD in RFC4861 and I would rather like to see the node requirements document say the same thing.

   - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Aug 2010 10:55:47 +1200

Isn't this a case where what we really want is MUST implement and SHOULD enable?

If I bought a router, I would expect it to be capable of redirecting but
I might want to disable it.

Regards
   Brian

On 2010-08-13 07:47, Alain Durand wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Bob Hinden <[email-masked]>
Date: Thu, 12 Aug 2010 17:17:24 -0700

> I might want to disable it.

Makes sense to me.

Bob

---

From: Alain Durand <[email-masked]>
Date: Thu, 12 Aug 2010 18:32:25 -0700

> I might want to disable it.

It probably depend on what kind of router.. If you only have point to point link, what is the value of mandating to implement redirects?

   - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Aug 2010 15:42:29 +1200

> It probably depend on what kind of router.. If you only have point to point link, what is the value of mandating to implement redirects?

Certainly, and it would be hard to test conformance in that case. We need wording
that doesn't force people to do pointless work, I guess.

     Brian

---

From: Pekka Savola <[email-masked]>
Date: Fri, 13 Aug 2010 08:57:47 +0300 (EEST)

On Thu, 12 Aug 2010, Alain Durand wrote:
> It probably depend on what kind of router.. If you only have point 
> to point link, what is the value of mandating to implement 
> redirects?

I've yet to see a router that only implements point-to-point 
interfaces.

-- 
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: Alain Durand <[email-masked]>
Date: Fri, 13 Aug 2010 06:06:49 -0700

> I've yet to see a router that only implements point-to-point 

It seems that those days, most (if not all) links in service provider networks are point to point.
You find ethernet shared access mostly in leaf networks, such as home or enterprises.

   - Alain.

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Aug 2010 23:10:25 +0900

> networks are point to point.

there are the occasional rare shared uses at exchange points.

> You find ethernet shared access mostly in leaf networks, such as home

yep.

the point is, do not put in requirements that make difficult or break
normal operations.

randy

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 13 Aug 2010 09:45:01 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alain Durand
Sent: Friday, August 13, 2010 9:07 AM
To: Pekka Savola
Cc: [email-masked]; [email-masked]; [email-masked]; Brian E
Carpenter; [email-masked]
Subject: Re: Router redirects in Node Requirements document

>You find ethernet shared access mostly in leaf networks, such as home
or enterprises.

I agree with Brian Carpenter and Bob Hinden - if the node is a router,
the node MUST implement Redirect and SHOULD enable Redirect
functionality and have the Redirect functionality configurable.  Even if
a router exists in the Internet core with one interface on the router
connected in a point to point link, there are several other interfaces
on the routers for which the router MUST implement Redirect
functionality.  There is a separate question that typically such P-P
links in the core are SONET interfaces on a router.  Such SONET
interfaces do not even have ND available to configure on the interface.
So where does the question of any existing functionality breaking come
in? 

Hemant

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Aug 2010 23:50:09 +0900

> Even if a router exists in the Internet core with one interface on the
> router connected in a point to point link, there are several other
> interfaces on the routers for which the router MUST implement Redirect
> interfaces do not even have ND available to configure on the
> interface.  So where does the question of any existing functionality
> breaking come in?

the vast majority of inte-router links today are p2p ethernet.  hence
the /127 draft, which this proposal is yet another religious attack on
actual internet operations.

randy

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 13 Aug 2010 10:33:33 -0500

-----Original Message-----
From: Randy Bush [mailto:[email-masked]] 
Sent: Friday, August 13, 2010 10:50 AM
To: Hemant Singh (shemant)
Cc: Alain Durand; Pekka Savola; [email-masked];
[email-masked]; [email-masked]; Brian E Carpenter;
[email-masked]
Subject: Re: Router redirects in Node Requirements document

>actual internet operations.

So this p2p ethernet could still be traversing over SONET in which case,
again, routers do not let ND be configured over such a link.  Anyway,
even if not SONET transport, if you have p2p inter router link, doesn't
each router have more network interfaces over which ND and Redirect
still needs to be supported?

Hemant

---

From: Ole Troan <[email-masked]>
Date: Fri, 13 Aug 2010 17:40:50 +0200

Hemant,

> still needs to be supported?

I'm not quite sure what the misunderstanding is here.
ND is supported on all multicast capable links, including the PPP encapsulation typically used on SDH.

cheers,
Ole

---

From: Shane Amante <[email-masked]>
Date: Fri, 13 Aug 2010 09:41:54 -0600

Henmant,

On Aug 13, 2010, at 09:33 MDT, Hemant Singh (shemant) wrote:
> again, routers do not let ND be configured over such a link.

It would be dumb to put Ethernet over SONET, (in these applications).  It's overwhelmingly p2p Ethernet over WDM or over dark fiber.

> Anyway,

Yes, that is the definition of a router.

-shane

---

From: Jared Mauch <[email-masked]>
Date: Fri, 13 Aug 2010 11:54:57 -0400

Agreed. Anyone wanting to do this is not connected with actual operations and should be questioned as to what the operational requirements are. Accepting and sending redirects also opens up dos vectors to devices when implemented poorly.

Jared Mauch

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 13 Aug 2010 11:00:33 -0500

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Friday, August 13, 2010 11:41 AM
To: Hemant Singh (shemant)
Cc: Randy Bush; [email-masked]; [email-masked];
[email-masked]; Pekka Savola; [email-masked]; Brian E Carpenter
Subject: Re: Router redirects in Node Requirements document

>ND is supported on all multicast capable links, including the PPP
encapsulation typically used on SDH.

I met a Service Provider (SP) from Japan at IETF 78 who told me he has
routers from popular vendors in Internet P2P links that do not let him
configure ND on SONET p2p links. I can contact him and get more details.
Anyway, that is not the point.  The point is that P2P inter-router link
is no justification to change the "MUST implement Redirect functionality
by a router".  A router has more than one network interfaces over which
ND Redirect MUST be implemented.  One should also be able to disable
Redirect on a router interface - there are networks like cable broadband
where hosts are always off-link. 

Hemant

---

From: Pekka Savola <[email-masked]>
Date: Fri, 13 Aug 2010 19:03:10 +0300 (EEST)

> You find ethernet shared access mostly in leaf networks, such as home or enterprises.

When writing an implementation, the router vendor has no way of 
knowing whether an Ethernet link is used to connect only two routers, 
or something else.  So it needs to implement redirects.

Further, an Ethernet link that connects two routers is not by default 
a point-to-point link from 1) RFC4861 perspective or 2) interface 
flags perspective (whether ND is used for address resolution) like 
SONET. As far as I know, it is not even possible to configure e.g. 
Juniper routers to do either 1) or 2).

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 13 Aug 2010 11:07:44 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jared Mauch
Sent: Friday, August 13, 2010 11:55 AM
To: Randy Bush
Cc: ipv6 deployment prevention
Subject: Re: Router redirects in Node Requirements document

>Agreed. Anyone wanting to do this is not connected with actual
operations and should be questioned as to what the operational
requirements are. Accepting and sending redirects also opens up dos
vectors >to devices when implemented poorly.

If you have a problem with ND Redirect being a DOS vector, then you
should have raised an issue with RFC 4861.  Anyway, RFC 4861 is clearly
aware of the DOS vector with Redirect, because RFC 4861 mentions
Redirect rate limiting in section 8.2.  DOS vector is a very weak reason
to shoot down "Redirect functionality MUST be implemented by a router in
the Node Req document".

[A router SHOULD send a redirect message, subject to rate limiting,]

Hemant

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Aug 2010 08:52:10 +1200

> It would be dumb to put Ethernet over SONET, (in these applications).  It's overwhelmingly p2p Ethernet over WDM or over dark fiber.

So, you need to be able to disable ND and redirect on such links.
That doesn't let the implementor off from supporting them as part of
basic router functionality. That's what we're wordsmithing.

(And a link where you're doing that is *exactly* a link where the
/64 requirement doesn't apply, so /127 is fine. This does,
strangely enough, all fit together.)

    Brian

---

From: Jared Mauch <[email-masked]>
Date: Fri, 13 Aug 2010 17:33:42 -0400

Been typing during breaks in a 300+ mile trip. I was more speaking to the adverse impacts of v4 redirects BUT.....

Unless you think there is some awesome reason that people are going to need redirects that have multiple routers on the shared lan WITH hosts that are not speaking some dynamic routing protocol with said routers, redirects are unnecessary and promote bad architecture. If that is your goal, then I would understand what is going on here. I've seen a lot of poorly architected networks that have nearly broken or melted down due to abusing something that is feasible in this space. 

I'm not sure what the true use case is for redirects here. 

Jared Mauch

---

From: Rémi Després <[email-masked]>
Date: Sat, 14 Aug 2010 08:50:19 +0200

>      - the Destination Address of the packet is not a multicast

In my understanding, this says that a router that has no means to ever find a better next hop never needs to send a redirect message.
An simple unmanaged home gateway, for example, may therefore not need to support any redirect-message transmission. 
It may still have to process redirect messages received at its wan interface (at least if this interface is neither to a P2P link nor to a virtual link a la 6to4), but would not need a complete redirect functionality.

One approach in draft-ietf-6man-node-req-bis-05 could then be:
"Redirect functionality SHOULD be supported, subject to conditions set forth in section 8.2 of RFC 4861."

Regards,
RD

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 14 Aug 2010 18:46:48 -0500

-----Original Message-----
From: Jared Mauch [mailto:[email-masked]] 
Sent: Friday, August 13, 2010 5:34 PM
To: Hemant Singh (shemant)
Cc: Randy Bush; ipv6 deployment prevention
Subject: Re: Router redirects in Node Requirements document

>Been typing during breaks in a 300+ mile trip. I was more speaking to
the adverse impacts of v4 redirects BUT.....

>Unless you think there is some awesome reason that people are going to
need redirects that have multiple routers on the shared lan WITH hosts
that are not speaking some dynamic routing protocol with >said routers,
redirects are unnecessary and promote bad architecture. If that is your
goal, then I would understand what is going on here. I've seen a lot of
poorly architected networks that have nearly >broken or melted down due
to abusing something that is feasible in this space. 

>I'm not sure what the true use case is for redirects here. 

Again, sorry to be a nag but such a question should have been raised
when RFC 2461 or RFC 4861 were being discussed in the IETF.  The
Node-Req document is only putting in text for what is already agreed
upon in an RFC like the RFC 4861.  I suppose the community did find a
need for Redirect and that is why this functionality was added to IPv6
ND.  However, here is one use case and let anyone else chime from the
RFC 2461 and RFC 4861 development days for more use cases.

Indeed a multiple router deployment begs the need for Redirect.  The
other deployments where Redirect is necessary is where hosts acquire
addresses via DHCPV6.  DHCPv6 does not dole out prefix length with the
IPv6 address.  So the host does not know what destination is on-link to
the host.  Therefore, the host would send packets to the default
router(s).  Since the router knows what destination is on-link, the
router can issue Redirects.  For example, see this cable modem
deployment.  Two hosts are sitting behind a bridged cable modem.  A
switch behind the cable modems connects the two hosts.  Each host
acquires a global IPv6 address using DHCPv6 and the cable access
concentrator (a CMTS - cable modem termination system) serving the cable
modem sent an RA to the modem and the hosts with no PIO (Prefix
Information Option).  Such a RA signals to the hosts to send traffic to
the default router (the CMTS).  Now host, H1 sends traffic destined to
host, H2 to the CMTS.  During DHCPv6, the CMTS DHCPv6 relay agent
gleaned the fact that H2's is using a cable modem, CM1 (based on L2
cable control that uses a Service ID, SID).  Likewise, the CMTS also
knows H1 is behind CM1.  So when a packet sent from H1 destined for H2
arrives at the CMTS (also the first hop IPv6 router), the CMTS issues a
Redirect to H1 to communicate directly with H2.

Therefore, I am still for what Brian Carpenter suggested. Here is
proposed new text for Redirect.

"Redirect functionality SHOULD be supported.  If the node is a router,
Redirect functionality MUST be implemented and SHOULD be enabled by
default."

Hemant

---

From: Jared Mauch <[email-masked]>
Date: Sun, 15 Aug 2010 16:17:53 -0400

> RFC 2461 and RFC 4861 development days for more use cases.

I'd like to suggest the premise that people who have not been around and involved since low level numbered RFCS not be told they should have retroactively raised their concerns when not involved. :)

(Also, apologies for jumping in mid-process for the rest of my life ...)

> Redirect functionality MUST be implemented and SHOULD be enabled by

I'd like to recommend that it SHOULD NOT be enabled by default.  There are a number of cases where some default behavior (eg: "ip directed-broadcast") future becomes an operational risk.  Now this may be something that is left up to the discretion of a vendor and that wiggle room is available here.  I certainly don't mind if a CMTS solution has redirects enabled for DHCPv6 clients, but the idea they would get a delegation without prefix-length information in v6 seems to be broken IMHO.  Pushing this requirement onto a network core because it is a "router" is perhaps not the best solution due to someones arguably "broken" edge.  That certainly does not exist within IPv4 and I'm not sure why someone would set out to degrade the services provided in IPv4.

Additionally, the role of a device in the network may dictate the necessity of the redirect capability.  I certainly don't see a need of devices in a core role to be generating or listening to such noise.  Vendors have typically starved CPU resources on devices based on long-term supply chain capabilities making it hard or impossible to upgrade a devices that needs to handle such items in the software-path vs hardware.  (Yes, the rate-limiters help here, but any node that appears to misbehave does create customer-support inquiries even if it's not actually a problem, eg: high ping/traceroute times when "bgp scanner" runs in IOS).

Fixing DHCPv6 and adding prefix-length/mask seems a much more elegant solution vs pushing redirect capability upon a large swath of devices.

- Jared

(Willing to be educated if items are incorrect here).

---

From: Randy Bush <[email-masked]>
Date: Mon, 16 Aug 2010 05:40:40 +0900

>> "Redirect functionality SHOULD be supported.  If the node is a
>> router, Redirect functionality MUST be implemented and SHOULD be
>> enabled by default."
> 
> I'd like to recommend that it SHOULD NOT be enabled by default.  There
> are a number of cases where some default behavior (eg: "ip
> directed-broadcast") future becomes an operational risk.  Now this may
> be something that is left up to the discretion of a vendor and that
> wiggle room is available here.  I certainly don't mind if a CMTS
> solution has redirects enabled for DHCPv6 clients, but the idea they
> would get a delegation without prefix-length information in v6 seems
> to be broken IMHO.  Pushing this requirement onto a network core
> because it is a "router" is perhaps not the best solution due to
> someones arguably "broken" edge.  That certainly does not exist within
> IPv4 and I'm not sure why someone would set out to degrade the
> services provided in IPv4.
> 
> Additionally, the role of a device in the network may dictate the
> necessity of the redirect capability.  I certainly don't see a need of
> devices in a core role to be generating or listening to such noise.
> Vendors have typically starved CPU resources on devices based on
> long-term supply chain capabilities making it hard or impossible to
> upgrade a devices that needs to handle such items in the software-path
> vs hardware.  (Yes, the rate-limiters help here, but any node that
> appears to misbehave does create customer-support inquiries even if
> it's not actually a problem, eg: high ping/traceroute times when "bgp
> scanner" runs in IOS).

i suspect that the problem many folk may have with saying "If the node
is a router, redirect functionality MUST be implemented but SHOULD NOT
be enabled by default," is that they fear that it will not get turned on
in the vast majority of cases, many where it would 'help' (fix
brokenness).

it's like what i call "do-gooder software," when it patches over
something broken, people never notice and say thanks.  when it makes one
error, all hell breaks out.  i think you make the point that the latter
is gonna happen.

> Fixing DHCPv6 and adding prefix-length/mask seems a much more elegant
> solution vs pushing redirect capability upon a large swath of devices.

heresy!!!  we're not hear to make moving from v4 to v6 easy.  we're here
to show infidels the 'right' way of doing things.

randy

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 15 Aug 2010 19:35:17 -0500

-----Original Message-----
From: Jared Mauch [mailto:[email-masked]] 
Sent: Sunday, August 15, 2010 4:18 PM
To: Hemant Singh (shemant)
Cc: Randy Bush; ipv6 deployment prevention
Subject: Re: Router redirects in Node Requirements document

I and Wes disagree with adding any prefix length to DHCPv6.  I believe
Wes gave the reason to 6man mailer during the past 3 years.  Rather than
spend time to fish out the email, here is the text Wes that captures the
gist of it.

"The reason I think one separated prefix length from ND RA and DHCPv6 is
that the router knows best what prefixes it can route to, and what is
on-link/off-link, etc., because the router is responsible for the
TOPOLOGY of the network.  The DHCPv6 server knows best who is authorized
to get an address, and what configuration information a client should
get, because it is the  CONFIGURATION/SECURITY authority. These are two
separate concerns, and it is best to keep them separate.  It's easier to
manage TOPOLOGY in a distributed fashion.  It's easier to manage
CONFIGURATION/SECURITY in a centralized fashion."

Hemant

---

From: Randy Bush <[email-masked]>
Date: Mon, 16 Aug 2010 09:40:52 +0900

> I and Wes disagree with adding any prefix length to DHCPv6.

one would not want to make it easy for enterprise and transit operators
to add ipv6 to their networks.  first they have to pray at the one true
religion, configure everything differently, and follow the instructions
of those wise ones who do not operate networks.

get a fracking clue!

randy

---

From: Jared Mauch <[email-masked]>
Date: Sun, 15 Aug 2010 21:06:49 -0400

> CONFIGURATION/SECURITY in a centralized fashion."

Oh my.

So, hosts shouldn't have to know anything about their environment anymore and this is just proxy-arp & redirects all over again?

Do you know what impact that has on IOS based devices?  I suspect you've not seen the operational impact as a result of such items, otherwise you would understand how poorly vendors actually implement these features for the operators. (Hence me raising the DoS issue).

Even with your aforementioned rate-limit items, this would possibly cause HA issues with switchover should a prefix/next-hop change, or a router fail.

Is there a legitimate operational reason a host should not know the subnet length it sits on?

- Jared

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 15 Aug 2010 21:22:43 -0500

-----Original Message-----
From: Jared Mauch [mailto:[email-masked]] 
Sent: Sunday, August 15, 2010 4:18 PM
To: Hemant Singh (shemant)
Cc: Randy Bush; ipv6 deployment prevention
Subject: Re: Router redirects in Node Requirements document

>I'd like to recommend that it SHOULD NOT be enabled by default.  

Please understand one point I made earlier on this thread.  The IPv6
node-req-bis document is capturing what is specified already in RFC 4861
for Redirect.  So if you want the node-req-bis document to specify
anything contrary to RFC 4861 and Redirect, you have to take that up as
a separate discussion on RFC 4861 and Redirect.  We should not stall the
node-req-bis document.  Another issue should be clear.  Redirect
functionality is a SHOULD for router since RFC 2461 and has continued to
be a SHOULD in RFC 4861.  So router vendors have shipping gear that
enables Redirect by default based on this SHOULD.  Also, since the fact
is known about the Redirect default on a router to be enabled, one can
always disable the functionality before use of the router in their
network.

I said what I had to say on this Redirect subject.

Hemant

---

From: Randy Bush <[email-masked]>
Date: Mon, 16 Aug 2010 12:29:18 +0900

> a separate discussion on RFC 4861 and Redirect.

seems to me that, first, we should try to understand what is the right
engineering.  then the professional standards folk can figure out how to
make sausage out of it.

> We should not stall the node-req-bis document.

when someone tells me it's a rush, i slow down and look around and
wonder why i am being asked to rush.

> Redirect functionality is a SHOULD for router since RFC 2461 and has
> continued to be a SHOULD in RFC 4861.

should implement or should enable by default?  8.2 says

and i am trying to understand this from two viewpoints

  o is this specifying default behavior?  i think you can make a case
    for this.  so, if we think it is best engineering not to have it
    default, this would need to be clarified.

  o what this says about p2p links, in particular how this affects the
    discussion of /127 p2p links.  that second condition might be
    construed as not being satisfied.  could someone please clarify?

> since the fact is known about the Redirect default on a router to be
> enabled, one can always disable the functionality before use of the
> router in their network.

or vice versa.

randy, who has been bitten by interfaces being chatty by default so is
       still trying to understand

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Aug 2010 16:26:10 +1200

Jared,

On 2010-08-16 13:06, Jared Mauch wrote:
...
> Is there a legitimate operational reason a host should not know the subnet length it sits on?

It needs to know, which is why this is part of the basic information
in RAs. Um, trying to run without RAs won't get you very far in IPv6.
The question seems to be whether the information should be repeated in DHCP.

    Brian

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 16 Aug 2010 09:18:58 +0200

Hi Pekka:

Redirect is almost useless on non-transitive links (NBMA) at large, not
only P2P.
Radios being non-transitive, you'll see more and more of those beasts.
And a radio router usually uses only radios. So there's a whole family
of routers that have strictly no use of redirect.
If we decide to must something, I would thus associate the MUST to the
categories of interface that the router supports.

Best,

Pascal

> Pekka Savola
> Sent: Friday, August 13, 2010 7:58 AM
> To: Alain Durand
to
> > point link, what is the value of mandating to implement redirects?
> 
interfaces.

---

From: Mark Smith <[email-masked]>
Date: Mon, 16 Aug 2010 19:13:03 +0930

On Sun, 15 Aug 2010 16:17:53 -0400

> Fixing DHCPv6 and adding prefix-length/mask seems a much more elegant solution vs pushing redirect capability upon a large swath of devices.

I'm don't understand at all how DHCPv6 prefix-length/mask would prevent
the situation that redirects are trying to address.

The situation occurs when a router knows more about the prefixes/nodes
on the link than the onlink node that sent the packet in the first
place. It seems to me that redirects are there to fill in the sending
node's prefix knowledge gap, during a transient situation. If nodes
fully know all the onlink prefixes, via correctly configured RA PIO
options, then redirects won't occur.

It seems to me that arguing against redirects is actually arguing for
having a common case, rather than an transient one, of nodes that don't
have full onlink prefix knowledge. I think having all nodes attached to
the link (i.e. both hosts and routers) being fully aware of all onlink
prefixes is a much better idea.

Regards,
Mark.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 16 Aug 2010 10:10:47 -0500

Pascal,

ND has always been scoped per interface and so has been RFC 4862.  That
is why existing routers support configurable redirects per interface.
Therefore something that is that clear about ND and Redirect, why do we
have to add more text to the node-req-bis document related to
per-interface?   The text I and Brian Carpenter proposed still makes
sense - a router MUST implement Redirect functionality and SHOULD enable
Redirect functionality by default. I already said last night, we have
shipping routers since the days of RFC 2461 that Enable redirect on a
network interface by default because RFC 2461 mandates, a router SHOULD
send a Redirect.  

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pascal Thubert (pthubert)
Sent: Monday, August 16, 2010 3:19 AM
To: Pekka Savola; Alain Durand
Cc: [email-masked]; [email-masked]; [email-masked]; Brian E
Carpenter; [email-masked]
Subject: RE: Router redirects in Node Requirements document

Hi Pekka:

Best,

Pascal

--------------------------------------

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 16 Aug 2010 10:44:14 -0500

-----Original Message-----
From: Jared Mauch [mailto:[email-masked]] 
Sent: Sunday, August 15, 2010 9:07 PM
To: Hemant Singh (shemant)
Cc: Randy Bush; ipv6 deployment prevention; Wes Beebee (wbeebee)
Subject: Re: Router redirects in Node Requirements document

>So, hosts shouldn't have to know anything about their environment
anymore and this is just proxy-arp & redirects all over again?

Not quite.  The cable deployment I gave a use case for Redirect with,
has hosts that know their traffic has to be sent to the default router.
I also said, the cable deployment has hosts as always off-link to each
other - if you are my neighbor, then your PC phone call talks to my PC
phone call by sending traffic to the CMTS.  Thus, the hosts completely
know what their environment is.    

>Do you know what impact that has on IOS based devices?  I suspect
you've not seen the operational impact as a result of such items,
otherwise you would understand how poorly vendors actually implement
>these features for the operators. (Hence me raising the DoS issue).

At least the high-end Cisco CMTS routers (ubr10000) I develop code for
has rate-limiting for any DoS issue.  Other Cisco routers will also have
a generic rate limiting that will limit the Redirect DoS too. 

>Even with your aforementioned rate-limit items, this would possibly
cause HA issues with switchover should a prefix/next-hop change, or a
router fail.

In my cable use case for Redirect, a RP card switchover still has the
CMTS pointing the hosts in the downstream to the same prefix and
next-hop.  Anyway, I am not sure how HA and switchover has any impact on
ND Redirect.  We need a more specific case by case evaluation and see
what problems do we have with Redirect.

>Is there a legitimate operational reason a host should not know the
subnet length it sits on?

Another reason is if both the ND RA and DHCPv6 send prefix length's what
if the information from two sources is different?  One can fat-finger a
DHCPv6 server configuration or the router IPv6 ND RA configuration.  Who
wins? 

Hemant

---

From: Jared Mauch <[email-masked]>
Date: Mon, 16 Aug 2010 12:17:13 -0400

> prefixes is a much better idea.

Not really, it's about the role of a device in a network.

If there are multiple subnets within a single broadcast domain that require redirects to tell the hosts about what is on-link, it's much better to actually configure your host correctly (or have it actively participate vs passively via redirects) so they have knowledge of these additional subnets.

If you're for random slop on a link, then redirects may be helpful, but that's not something that is architected well.  I can't think of anyone that actually would PLAN for that type of environment.  Most cases I've seen it involve into a mess over time.  Preventing a mess and shifting the burden is what I'm speaking out about here.

I've known many host guys who treat routers (and switches) as a "black box" that gets their packets/frames there.  Sending them messages about alternate reachability of prefixes is useful in a trusted environment.  Without authenticating those messages (ie: speaking in an active IGP) it can quickly become less useful noise and actually inhibit communication.

All I've heard is that "someone might put two different subnets on the same broadcast domain and want helper messages to make a better decision" vs "redirects are REQUIRED to maintain reachability between end nodes".

That is where I take issue with the tact being taken here.

Requiring that a router send and hosts listen to these messages introduces complexities to the system.  I can't get my vendors to produce stable router software in 2010, let alone expect the diverse business-units within the vendors to actually get this complexity right.  Making something which I surely agree is a "nice to have" (due to latency reduction and other various intrinsic benefits) a requirement is shifting the burden and introducing complexity (to hosts and routers) where it's not necessary.  Just because you can build it with "redirects" does not make it good or a desirable solution.

- Jared

---

From: Jared Mauch <[email-masked]>
Date: Mon, 16 Aug 2010 12:50:23 -0400

> know what their environment is.    

So it's a non-issue and they don't need the redirects in this case it seems.

> a generic rate limiting that will limit the Redirect DoS too. 

Yeah, I'm speaking generically, but knowing how each product team at Cisco works, it's very hit-or-miss if the folks who implement the code understand what they are doing (sadly).

> what problems do we have with Redirect.

I'm speaking about an environment where RP switchover is not as "hitless" as marketing material may represent itself.  Being practical about these things, we have often found that 1+1 RP redundancy causes as many problems as it solves.  Typically HSRP/VRRP can provide solutions in a L2 environment.  It may be different in your CMTS case due to the nuances of the media(RF).

> DHCPv6 server configuration or the router IPv6 ND RA configuration.  Who

One can also fat-finger a default route or "reload in 1 ; wr erase" too.

Just because someone can poorly manage their network doesn't mean you should be advocating it.  I'm not sure I see any operational "win" here.  If you step outside the CMTS world, you typically have better defined subnets/masks on devices running IOS/XR/XE/JunOS/JunOS-E/NxOS even when the device is acting as a DHCP server doing ND RA (vs lots of diverse subnets coming in; biz vs consumer vs voip).

It seems there is only nominal value to your CMTS example, and the problems of additional code complexity on devices where it's not necessary elsewhere in a providers network (eg: a core router with well defined subnets which are not moving targets w/ radius et al).

- Jared

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 16 Aug 2010 19:37:20 -0500

-----Original Message-----
From: Jared Mauch [mailto:[email-masked]] 
Sent: Monday, August 16, 2010 12:50 PM
To: Hemant Singh (shemant)
Cc: Randy Bush; ipv6 deployment prevention; Wes Beebee (wbeebee)
Subject: Re: Router redirects in Node Requirements document

>So it's a non-issue and they don't need the redirects in this case it
seems.

No, it is an issue.  Did you see my email for the detailed use case that
two neighboring homes with two different bridged cable modems have to
talk to each other throught the SP first hop router (CMTS).  But the
redirect example I gave was for two hosts behind the same cable modem in
the same home - when one host sent traffic to the other via the SP first
hop router, the router HAD to send a Redirect!

>Just because someone can poorly manage their network doesn't mean you
should be advocating it.  I'm not sure I see any operational "win" here.
If you step outside the CMTS world, you typically have >better defined
subnets/masks on devices running IOS/XR/XE/JunOS/JunOS-E/NxOS even when
the device is acting as a DHCP server doing ND RA (vs lots of diverse
subnets coming in; biz vs consumer vs voip).

Even outside of the CMTS world, soon as one has a LAN network with more
than one router, one can easily see a need for Redirect - google for so
many examples of LAN networks where Redirect is used.   Also, the
examples for other OS and vendors and DHCP server in the same router is
all moot - the same router sends the ND RA and the DHCPv6 server will
not send the prefix len in DHCPv6 responses.

Again, summary to the mailer:

I still haven't seen any justification for changing the "MUST implement
Redirect functionality by a router" - there are sufficient use cases and
needs and also DoS issue with Redirect is weak reason to change the
MUST.  Now, it's only SHOULD enable by default or not that needs debate.
For the 3rd time, since RFC 2461, router vendors enable Redirect by
default.  Howsoever folks may thrash one cannot ignore legacy.   So why
do we have to thrash so much and just agree to the SHOULD enable by
default?  

Hemant

---

From: Jared Mauch <[email-masked]>
Date: Mon, 16 Aug 2010 23:32:54 -0400

> hop router, the router HAD to send a Redirect!

So, you are in favor of wasting the RF space by making the packet have increased latency through a remote device not in-home for in-home communication?  I knew that docsis/cmts were a bit strange, but you really expect the hosts to be doing this?  

Is there a cable provider doing such crazy routing activity today?  I doubt it.

It sounds like you support:

Having two hosts on the same LAN (in-home) sending all their traffic via the CMTS increasing the limited upstream/downstream network utilization vs having the hosts have properly scoped subnet masks.

I support:

requiring a host that has an IPv6 address to explicitly have some sort of mask (eg /48 /64 /96 ALL examples) configured.  Having the host think it's an island unto itself (/128) and relying upon the grace of technology to direct it places additional load on the actual network devices.
> not send the prefix len in DHCPv6 responses.

I did not realize you spoke for google.  I will rely upon my colleagues that work there to tell me what google does.

As an operator of a network that may have more than one router on a lan, the reasons for this are generally one of two reasons:

1) Internet Exchange Point (we use BGP here to make forwarding decisions, not redirects)
2) HSRP/VRRP redundancy

Even if you assume that someone picks the not-listed 3rd choice of placing their routers and some other (eg: dns, radius, dhcp) services all in the same subnet (poor network design, even for networking 101) making your fancy asic or processor based devices forward the packets correctly would seem to induce the proper situation.  There is also nothing preventing these hosts (dns, radius, dhcp) from speaking some dynamic routing protocol to make better decisions.  If there's more than one router on the lan, how do they communicate in your case?  telekinesis?  If these end hosts need to make "better" decisions, there is nothing preventing them from participating.  The method you defend is redirects.  The method I recommend is proper participation in the routing topology.

> do we have to thrash so much and just agree to the SHOULD enable by

because my routers don't operate via telekinesis or redirects.  my hosts don't listen to redirects as the information may be forged or improper.

Your "haven't seen any justification" is purely smoke for making a host make routing decisions (via redirects; making it a router it seems?) but not requiring it to actually participate in the network.

If you want your hosts to be routers, call them routers (and make them participate in the network) and don't try to play mix-and-match.

- Jared

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Aug 2010 16:13:58 +1200

Jared

...
> because my routers don't operate via telekinesis or redirects.  my hosts don't listen to redirects as the information may be forged or improper.

So why can't you disable redirects? If they are configured on by default,
it will be possible to configure them off.

I understand that you don't want to use redirects. What I don't understand
is why you don't want other people to be able to use them.

    Brian

---

From: Randy Bush <[email-masked]>
Date: Tue, 17 Aug 2010 14:21:57 +0900

>> because my routers don't operate via telekinesis or redirects.  my
>> hosts don't listen to redirects as the information may be forged or
>> improper.
> 

<speaking for jared>

he does not want others not to be able to use them.  nowhere has he said
that.  if they want them, turn them on.  same argument.

his point is that having interfaces do things automatically by default
has been demonstrated to be dangerous.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Aug 2010 17:47:05 +1200

> that.  if they want them, turn them on.  same argument.

Right, except that this would reverse the earlier consensus, since RFC4861
says
   A router SHOULD send a redirect message, subject to rate limiting,
   whenever it forwards a packet that is not explicitly addressed to
   itself

> has been demonstrated to be dangerous.

I assume that's why 4861 also gives a longish list of validity checks
that a host must apply to any redirect before believing it.

Anyway, having (re)read that part of 4861, I need to reverse myself
a bit. We can't let hosts off the hook; they need to do what 4861 says.
But if there's a valid reason to ship a router with redirects turned
off (i.e. a valid reason to override the SHOULD I just quoted), I don't
see that Node Requirements can forbid it. So I guess we'd end up with

   Redirect functionality SHOULD be supported.  If the node is a router,
   Redirect functionality MUST be supported but MAY be disabled by default.

     Brian

---

From: Eric Gray <[email-masked]>
Date: Tue, 17 Aug 2010 08:47:18 -0400

Jared,

	Actually, if you look at the question from a slightly different
perspective, there is more than one "legitimate operational reason."

	The "recast" version of the question is what is the cost to the
network if a host IS required to know this information (for reasons 
having not a lot to do with making the host itself work correctly),
and "knows" incorrect information?

	The first (and probably most important) reason why networks 
should not depend on hosts having the correct information, is the 
likelihood that a host (which may or may not be under the operational 
control of the network operator) might be misconfigured.  

	DHCP has done much to fix this problem, at least for the hosts
that are cooperative.  But there is always the possibility that the
need to keep the host updated (via DHCP, for instance) may be less
than healthy for the host.  And - quite frankly - the host does not 
really need to know this information in most cases.

	A second reason is more philosophical (though the above reason
is one aspect of this higher-level "philosophical" reason) - it is
not a good idea in general to force a "need-to-know" on entities that 
do not themselves have an existing "need-to-know."  Doing so has the
undesirable effect of increasing the amount of knowledge that needs
to be correctly "spread around."

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jared Mauch
Sent: Sunday, August 15, 2010 9:07 PM
To: Hemant Singh (shemant)
Cc: ipv6 deployment prevention
Subject: Re: Router redirects in Node Requirements document

Oh my.

- Jared

---

From: Mark Smith <[email-masked]>
Date: Tue, 17 Aug 2010 22:44:53 +0930

Hi Jared,

On Mon, 16 Aug 2010 12:17:13 -0400

> If there are multiple subnets within a single broadcast domain that require redirects to tell the hosts about what is on-link, it's much better to actually configure your host correctly (or have it…

That's exactly what I was saying regarding having RAs announce all
onlink prefixes, so that end-nodes are fully informed.

> If you're for random slop on a link, then redirects may be helpful, but that's not something that is architected well.  I can't think of anyone that actually would PLAN for that type of environment.

Agree. I think of redirects as fixups during a transient situation, not
a normal operational one. 

>  Most cases I've seen it involve into a mess over time.  Preventing a
> mess and shifting the burden is what I'm speaking out about here.

I suppose that comes down to whether networks should try to be
tolerant to misconfiguration or not. I think the robustness principle
suggests that networks should - "if there is a possibility it'll work,
give it a try".

> That is where I take issue with the tact being taken here.

I don't think that is the case.

> Requiring that a router send and hosts listen to these messages introduces complexities to the system.  I can't get my vendors to produce stable router software in 2010, let alone expect the diverse business-units within the vendors to actually get this complexity right.

However, how does lessening the requirements in RFCs cause vendors to
increase the quality of their implementations? There aren't bugs in
absent features. Bugs occur in features that haven't been implemented
well.

I think the best place to solve problems is where they're caused. Bad
implementations usually aren't the fault of RFCs (unless the RFCs
aren't good in the first place), they're the fault of the implementer,
so at the implementer should be where they're fixed. If they don't want
to do that, then they deserve appropriate consequences (loss of
business, etc.)

>  Making something which I surely agree is a "nice to have" (due to
>  latency reduction and other various intrinsic benefits) a requirement
>  is shifting the burden and introducing complexity (to hosts and
>  routers) where it's not necessary.

I think that's assuming that bandwidth in and out of a router's
interface is high, such that the cost of constantly hair pinning
traffic back onto the link it came from is cheaper than the cost of
identifying when to send a redirect and sending one. That's usually
the case on high speed LAN interfaces, but may not be in other
environments.

I agree that there are quite a number of cases where hair pinning is
cheaper, however I don't think it is in all cases. I agree with the
suggested text Brian Carpenter posted -

"Redirect functionality SHOULD be supported.  If the node is a router,
Redirect functionality MUST be supported but MAY be disabled by
default."

Regards,
Mark.

---

From: Jared Mauch <[email-masked]>
Date: Tue, 17 Aug 2010 09:32:07 -0400

> really need to know this information in most cases.

Poorly configured and behaving network elements (hosts, routers) will always exist.  Building a fault-tolerant system should be a goal, but this requires cooperation.

> to be correctly "spread around."

Correct, so spreading network topology information via redirects is not an ideal situation as they don't need to know.

As a host, I need to know what is on-net and what should be forwarded to my router (default gateway).

As a router, I need to know my topology, and in the event "I don't know", there may exist a higher level authority (default) to direct my packets/frames/cells/modulation to.

- Jared

---

From: Jared Mauch <[email-masked]>
Date: Tue, 17 Aug 2010 09:43:44 -0400

> absent features. Bugs occur in features that haven't been implemented

Actually, you are missing some major theory here due to code complexity.  Vendors have stats on defects per line of code, now take the following:

receive_packet_loop()
{
  rx_pkt();
  lookup_nh();
  tx_pkt();
}

vs

router:

receive_packet_loop()
{
  rx_pkt();
  lookup_nh();
  if (pkt.iif == pkt.oif) {
    check_rate_limiters();
    send_redirect();
  }
  pkt.ttl--;
  tx_pkt();
}

host:
receive_packet_loop()
{
  rx_pkt();
  if (pkt.isredirect)
  {
    check_redirect_valid();
    update_routing_table();
    run_routing_table_aging();
  }
}

You are introducing a lot of complexity to a system that honestly does not need it.

> cheaper, however I don't think it is in all cases.

	I can imagine cases where a transient network event would make redirects useful, but if a user has HA requirements, their overall architecture should incorporate these via some other process (eg: HSRP/VRRP/CARP).

> I agree with the

I certainly think it's better, but once again, we have experienced network outages as a consequence of IPv6 redirects being silently enabled by default by broken vendors implementations due to this further code complexity and load placed upon the RE/RP.

Here's a sample (random, yeah right) router interface in our network facing a host:

interface X
 description BM: puck.nether.net - local wire
 ip address 204.42.254.1 255.255.255.240
 no ip redirects
 no ip proxy-arp
 ip pim bsr-border
 ip pim sparse-mode
 ip multicast boundary 62
 ip route-cache same-interface
 ip route-cache flow
 logging event link-status
 load-interval 30
 no keepalive
 speed 1000
 duplex full
 ipv6 address 2001:418:3F4::1/64
 ipv6 enable
 no ipv6 redirects
 ipv6 nd suppress-ra
 no mop enabled
 hold-queue 3584 in

- Jared

---

From: Thomas Narten <[email-masked]>
Date: Thu, 19 Aug 2010 14:23:07 -0400

> However, draft-ietf-6man-node-req-bis-05.txt refer to the normative
> text on Neighbor Discovery, ie RFC4861 that says: Section 8.2:

> It seems that the Node requirement text is going above and beyond
> what is required by RFC4861, transforming the SHOULD into a MUST.

Note, this change was actually made by RFC 4294, way back when. The
current ID hasn't changed that.

> I might have missed (or do not remember) the discussion, is there a
> reason for this change? And shouldn't the ND spec have been changed
> first to allow to upgrade the SHOULD into A MUST?

One the realities we have to deal with is that some of our specs were
written a long time ago, and things you might think today need to be
said explicitly, simply weren't.

My recollection as a co-author of ND is that it was always assumed
that *all* routers would implement redirects. This was so obvious, it
just wasn't deemed necessary to write explicitly in the draft. The
SHOULD language above, is about when to actually send a redirect, not
about whether to implement the functionality itself. There are times
when (for a given packet) it wouldn't be appropriate to send one. But
that would be a run time decision, not an "implement or not" decision.

> For the record, I support the SHOULD in RFC4861 and I would rather
>  like to see the node requirements document say the same thing.

The other problem we are now dealing with is that IETF documents have
exactly two classes of devices: hosts and routers. And maybe even more
explicitly, routers and non-routers. This comes from the basic
definition (from RFC 2460):

>    host        - any node that is not a router.  [See Note below].
> 
>    router      - a node that forwards IPv6 packets not explicitly
>                  addressed to itself.  [See Note below].

The reality is that the Internet ecosystem has a wide variety of
devices now, and many don't cleanly fit into either category. Even
routers are hosts, when they act as the sender or originator of
traffic.

Even with routers, this thread talks about edge routers (those on
networks where hosts connect) and SP internal links (which are mostly
or always p2p). Clearly, we could could think of functionality
critical for one type of device but irrelevant (or maybe worse) for
the other.

I don't think we are in a position with the node requirements document
to try and slice those kinds of hairs. We'll never get anywhere...

FWIW, I'm in favor of MUST implement, since the idea of a generic
edge router not implementing redirects seems like something we should
not encourage. Also, I'm not convinced yet that the cost of
implementing redirects is particularly a problem in the general case,
which is what this document is all about.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 19 Aug 2010 15:00:52 -0400

> If there are multiple subnets within a single broadcast domain that
>  require redirects to tell the hosts about what is on-link, it's
>  much better to actually configure your host correctly (or have it
>  actively participate vs passively via redirects) so they have
>  knowledge of these additional subnets.

The above is not the main reason for redirects.

If you have 2 routers on the link, a host will choose one (at random)
and forward traffic to it. If the host guesses wrong (for a particular
destination), the router should send a redirect directing the host to
use the other router instead (for that particular destination). The
host then updates its cache and forwards subsequent traffic to proper
router.

Redirects are a key part of the Internet architecture. Always have
been.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 19 Aug 2010 15:07:50 -0400

> >     the subnet length it sits on?

A host should not be *required* to know the subnet length.  Very
simple devices may have "simple" stacks. And indeed, for a simply
host, all you need to know is a first hop router address. Redirects
can do the rest.

This may not be the ideal situation, but it is one the architecure
allows for.

It is also fine for more sophisticated implementations to know what
the subnet length is.

> The question seems to be whether the information should be repeated

My conclusion is now yes. The obvious scenario is one that is in use
today in IPv4.

Hosts learn router addresses via DHCP. They also learn on-link prefix
info from DHCP. This is essentially static information and does not
change.

The network infrastructure (i.e., the first hop routers) all run VRRP
and handle faults and failovers without hosts having to do
anything. Works fine in IPv4 and is an appropriate choice for some
(emphasis on *some*) environments.

IPv6 should allow for the same functionality, to ease transision to
IPv6 for such networks.

I plan to resurrect an old DHC ID on this topic, as I view this is a
gap of the form "why can't I do what I do in IPv4 today in IPv6".

Thomas

---

From: Jared Mauch <[email-masked]>
Date: Thu, 19 Aug 2010 15:31:46 -0400

> host, all you need to know is a first hop router address. Redirects

If they can't handle to know an extra byte (mask) plus 128 bits for 'default'
gateway, I certainly understand small embedded solutions having limited space
but implementing the redirect codebase, aging, etc.. seems like a lot more
effort than knowing a mask and default gateway.

> This may not be the ideal situation, but it is one the architecure

Just because something is 'allowed' does not mean it should be encouraged.
I could announce vanity information in AS_PATH, but it's certainly not encouraged.

- Jared

---

From: Ralph Droms <[email-masked]>
Date: Thu, 19 Aug 2010 15:50:16 -0400

Being a little pedantic here...my understanding is that a host never knows a subnet length, per se.  What the host knows is a list of on-link prefixes, which it matches against outbound traffic.  A minimal implementation might not keep a list of on-link prefixes and send everything to its default router; redirects would do the rest...

- Ralph, who is sorry if he missed something earlier in the thread and is now pedanting up the wrong tree

---

From: [email-masked]
Date: Thu, 19 Aug 2010 21:59:56 +0200 (CEST)

> Being a little pedantic here...my understanding is that a host never knows a subnet length, per se.  What the host knows is a list of on-link prefixes, which it matches against outbound traffic.  A…

This is an important distinction in some situations - but will probably
be completely lost on most people coming from the IPv4 world, knowing
quite a bit about subnets. Of course they're going to assume subnets
work the same way in IPv6...

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Jared Mauch <[email-masked]>
Date: Thu, 19 Aug 2010 15:58:59 -0400

> Being a little pedantic here...my understanding is that a host never knows a subnet length, per se.  What the host knows is a list of on-link prefixes, which it matches against outbound traffic.  A…

If it goes to the default router, it will still get there (but maybe ttl--; as a side-effect).
> - Ralph, who is sorry if he missed something earlier in the thread and is now pedanting up the wrong tree

The reason I'm being pedantic about this is we have had network outages as a result of redirects being on by default as a hidden configuration option.  

I've similarly seen the same problem in ipv4 w/ redirects + proxy-arp taking out the device or driving the cpu load high enough that it impacts other protocls, etc..

Overall, while a "nice-to-have", it does damage network stability and SHOULD NOT be enabled by default.  this is why we put it in our interface templates to disable this capability.

Here's how many ipv6 interfaces we have enabled today with no adverse customer or infrastructure impact after this change.

cfgtools=> select count(*) from ipv6;
 count 
-------
  1600

- Jared

---

From: Jared Mauch <[email-masked]>
Date: Thu, 19 Aug 2010 16:08:57 -0400

> Redirects are a key part of the Internet architecture. Always have

Not sure if you actually looked at the configuration sampling I posted, but redirects are not actually used in networks these days.  The only places where i've seen it used are in "hacked together" networks and were removed.  While perhaps useful in the 80's and early 90's, there have been numerous cases where redirects have been harmful to networks that I've operated.

If you missed the configuration excerpt I posted, I can send it again to you in private.

- Jared

(who thinks suggesting that cidr was an key part of the internet infrastructure at one point surely means it's a good idea today too).

---

From: [email-masked]
Date: Thu, 19 Aug 2010 22:22:35 +0200 (CEST)

> Not sure if you actually looked at the configuration sampling I posted, but redirects are not actually used in networks these days.  The only places where i've seen it used are in "hacked together"…

Agreed, redirects should *not* be enabled by default.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 19 Aug 2010 17:54:55 -0400

> Agreed, redirects should *not* be enabled by default.

wow, longest thread about 2 words... ever.

Please take my vote as:
1) redirects MUST be implemented.
  I don't like them, they don't have auth info in them, but I can see
cases where they may be useful.
2) redirects MUST NOT be on by default
  I can see a vendor deciding that on platform X they choose to enable
redirects as a default. I hope that no router with more than 2
interfaces on it, and meant for 'not in the home' usage would choose
this path.

editorial-foo:
Quite a bit of the conversation seems like particular use cases being
abused for a point.

I can see that for large/core network devices there is no need, and
significant complexity in maintaining codebase with redirects. In
these places I'd prefer to just not have it included at all, but I
definitely don't need it on by default.

For enterprise-edge, CMTS, wireless deployments I can see that using
redirects may be more useful (leaving aside the issues Jared brings up
about 'well designed' network architectures) so having the codebase
there seems 'ok' to me, suggested configs and/or default configs on
those platforms may even have it enabled.

For home/cpe type deployments maybe it makes more sense to have this
enabled, so linksys/dlink/buffalo/etc could choose to just enable it,
worst case the consumers revolt and .... it gets disabled in the next
rev.

-chris

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 19 Aug 2010 17:00:05 -0500

For the 4th time to this mailer.  What do you do with shipping routers as of 10 years back that have Redirect enabled by default because of the SHOULD in RFC 2461 and RFC 4861?  Why is this point so hard to understand or being ignored?

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christopher Morrow
Sent: Thursday, August 19, 2010 5:55 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Router redirects in Node Requirements document

Please take my vote as:

editorial-foo:

-chris

---

From: Jared Mauch <[email-masked]>
Date: Thu, 19 Aug 2010 18:25:24 -0400

We disable them. We wish our vendors would expose these hidden defaults in their codebase (nvgen, etc). 

Just because it is in an rfc does not make it right :-) it should be changed. 

Jared Mauch

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 19 Aug 2010 18:05:13 -0500

Joel,

Ccing your reply to a broader audience.  I understand reason A below but
with a grain of salt.  I know for example, the deprecation of the RH0
header as such a change.  So the grain of salt is, I don't recommend the
IETF waffle without a formal document that captures the reason for the
change.  Folks do not remember emails later in future.  Does a short
Informational note make sense to write by someone who is most vocal here
and we take it from there?  

Comments?

Thanks,

Hemant

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, August 19, 2010 6:25 PM
To: Hemant Singh (shemant)
Subject: Re: Router redirects in Node Requirements document

A) The IETF has in the past, and will in the future, change things in 
ways that make old devices non-compliant.  If we find that the old 
advice was wrong, we change it.
B) Would it change your reaction if it were SHOULD NOT be on by default?

  I happen to think that paying attention to the operators desire for 
MUST NOT makes sense, but I wanted to better understand what iscausing 
you concern.

Yours,
Joel

---

From: Randy Bush <[email-masked]>
Date: Fri, 20 Aug 2010 10:12:23 +0900

> For the 4th time to this mailer.  What do you do with shipping routers
> as of 10 years back that have Redirect enabled by default because of
> the SHOULD in RFC 2461 and RFC 4861?

standards work != archeology

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 19 Aug 2010 21:48:29 -0400

> Just because it is in an rfc does not make it right :-) it should be changed.

yes. this seems like a case of something that looked like a great idea
12+ years ago (rfc2461  was published in 1998, LOTS of things have
changed since that time) but is upon reflection maybe not a great
idea.

Directed Broadcast is a super example of this same thing (perhaps not
rfc codified, but 'seems like a great idea, default on!' later 'doh!
worst idea ever, pls default off that "feature"').

-chris

---

From: Randy Bush <[email-masked]>
Date: Fri, 20 Aug 2010 11:32:42 +0900

> worst idea ever, pls default off that "feature"').

hdr0

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 20 Aug 2010 09:40:03 +0200 (CEST)

> Agreed, redirects should *not* be enabled by default.

+1.

I would much rather have the router forward the packet back the way it 
came as opposed to sending redirects. I believe this is the default when 
disabling redirects on most vendors, I'd like this to be default 
behaviour according to standard.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Fri, 20 Aug 2010 14:06:49 +0000

> changed since that time) but is upon reflection maybe not a great 

As codified 12 years ago, redirects were supposed to solve two problems: multiple subnets on the same link; and non-broadcast networks. The discussion on this list makes it pretty clear that the "multiple subnet" use case is rare enough, that redirects have harmful effects, and that they should not be enabled by default.  But if we do not have something like redirects, how do we handle non-broadcast networks? 

-- Christian Huitema

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 20 Aug 2010 10:41:53 -0400

> As codified 12 years ago, redirects were supposed to solve two problems: multiple subnets on the same link; and non-broadcast networks. The discussion on this list makes it pretty clear that the "m…

I think my stance (and jareds and mikael and stenar) was that having
redirects is good/acceptable, having them on by default is not
good/acceptable.

So... for 'non-broadcast' networks you enable that feature on the
interface(s) in question. Again, I can imagine some helpful instances
where the vendor codes the router to say: "Hey, that's a non-broadcast
interface, here I fixed it for ya!" though as Jared points out making
that sort of thing very, very obvious in the config AND docs would
certainly be nice as well.

-Chris

---

From: Alain Durand <[email-masked]>
Date: Tue, 24 Aug 2010 08:09:33 -0700

> which is what this document is all about.

This is where we differ. I do not believe that the requirement document should
make blanket statements that cover all routers when the benefits apply to only
a portion of the cases. We can debate how much this portion represent, but
the reality is that there is a significant cost to implement this on some hardware
and it is known that those card will not be in a situation where redirect will
ever make sense. This, to me, fits the very definition of SHOULD. You really
should do this (implement redirect) unless you have a really good reason not to.

   - Alain.

---

From: Alain Durand <[email-masked]>
Date: Tue, 24 Aug 2010 08:11:14 -0700

> Redirects are a key part of the Internet architecture. Always have

This is true for leaf networks where hosts share links with routers.
This is useless in the core of the Internet where you only have
point to point links.

  - Alain.

---

From: Alain Durand <[email-masked]>
Date: Tue, 24 Aug 2010 08:19:49 -0700

> As codified 12 years ago, redirects were supposed to solve two problems: multiple subnets on the same link; and non-broadcast networks. The discussion on this list makes it pretty clear that the "m…

How many of those NBMA networks do we have left? If redirects are helpful there, why do\n't we say in the requirement document, use it there, but do not bother elsewhere?

Back to my previous point, the fact that something can be useful in some cases is not a good basis to make it mandatory to implement everywhere.

Let's be practical here....

   - Alain.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 24 Aug 2010 10:22:03 -0500

Alain,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alain Durand
Sent: Tuesday, August 24, 2010 11:10 AM
To: Thomas Narten
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Router redirects in Node Requirements document

>there is a significant cost to implement this on some hardware

What is special about this hardware that a dinky router control plane
feature like the Redirect router functionality cannot be supported on
such hardware if the hardware already supports IPv6 ND? 

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 24 Aug 2010 11:22:50 -0500

Alain,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alain Durand
Sent: Tuesday, August 24, 2010 11:20 AM
To: Christian Huitema
Cc: prevention; [email-masked]
Subject: Re: Router redirects in Node Requirements document

>How many of those NBMA networks do we have left? If redirects are
helpful there, why do\n't we say in the requirement document, use it
there, but do not bother elsewhere?

Cmon, now.  I thought you worked for Comcast up till recently and their
cable network is one example of an NBMA network.  The cable deployment
in the U.S. alone is over at least 20 million data subscribers.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 24 Aug 2010 11:22:50 -0500

Alain,

-----Original Message-----

Hemant

---

From: Alain Durand <[email-masked]>
Date: Tue, 24 Aug 2010 09:53:37 -0700

1) To answer your point, I do not think there is a need for redirect in a cable network. Everything goes through the CMTS anyway.
2) Even if redirect could be useful in such a leaf network, it would not change my overall point. This is not an argument to mandate it
mandatory to implement for ALL networks.

  - Alain.

---

From: Alain Durand <[email-masked]>
Date: Tue, 24 Aug 2010 09:53:37 -0700

- Alain.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 24 Aug 2010 13:11:27 -0500

Alain,

-----Original Message-----
From: Alain Durand [mailto:[email-masked]] 
Sent: Tuesday, August 24, 2010 12:54 PM
To: Hemant Singh (shemant)
Cc: Christian Huitema; prevention; [email-masked]
Subject: Re: Router redirects in Node Requirements document

>1) To answer your point, I do not think there is a need for redirect in
a cable network. Everything goes through the CMTS anyway.

Not quite.  Did you happen to see this example I sent out on 08/14/2010
on this thread?

[For example, see this cable modem deployment.  Two hosts are sitting
behind a bridged cable modem.  A switch behind the cable modems connects
the two hosts.  Each host acquires a global IPv6 address using DHCPv6
and the cable access concentrator (a CMTS - cable modem termination
system) serving the cable modem sent an RA to the modem and the hosts
with no PIO (Prefix Information Option).  Such a RA signals to the hosts
to send traffic to the default router (the CMTS).  Now host, H1 sends
traffic destined to host, H2 to the CMTS.  During DHCPv6, the CMTS
DHCPv6 relay agent gleaned the fact that H2's is using a cable modem,
CM1 (based on L2 cable control that uses a Service ID, SID).  Likewise,
the CMTS also knows H1 is behind CM1.  So when a packet sent from H1
destined for H2 arrives at the CMTS (also the first hop IPv6 router),
the CMTS issues a Redirect to H1 to communicate directly with H2.]

>2) Even if redirect could be useful in such a leaf network, it would
not change my overall point. This is not an argument to mandate it
>mandatory to implement for ALL networks.

So are you asking for the text like this to change from MUST to SHOULD?

"A router MUST implement Redirect functionality"

Or are you OK with the MUST in the quoted sentence directly above and
would like to see a MUST implement and SHOULD NOT enable by default?  

Thanks,

Hemant

PS: I hope you are settled in VA now after your move from PA.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 24 Aug 2010 13:11:27 -0500

Alain,

-----Original Message-----
From: Alain Durand [mailto:[email-masked]] 
Sent: Tuesday, August 24, 2010 12:54 PM
To: Hemant Singh (shemant)
Cc: Christian Huitema; prevention; [email-masked]
Subject: Re: Router redirects in Node Requirements document

Thanks,

Hemant

---

From: Alain Durand <[email-masked]>
Date: Tue, 24 Aug 2010 11:26:33 -0700

> would like to see a MUST implement and SHOULD NOT enable by default?  

I'd like to see a SHOULD implement. I'd also like to see recommendation to NOT enabling it for point to point link.

  - Alain.

---

From: Alain Durand <[email-masked]>
Date: Tue, 24 Aug 2010 11:26:33 -0700

- Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Aug 2010 11:37:02 +1200

> I'd like to see a SHOULD implement. I'd also like to see recommendation to NOT enabling it for point to point link.

SHOULD, in IETF-speak, means "there may exist valid reasons in
particular circumstances to ignore a particular item, but the
full implications must be understood and carefully weighed before
choosing a different course." It seems to me that in a requirements
document, SHOULD needs to be accompanied with a brief description
of possible valid reasons to ignore it. Such as
 Redirect functionality could reasonably be omitted if the
 implementation in question is limited to support only
 interfaces for point to point links or non-broadcast
 multiple access links.
If you don't do that, we know that the SHOULD will definitely be
misused by sloppy product managers.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Aug 2010 11:37:02 +1200

Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 25 Aug 2010 08:06:58 +0300 (EEST)

> This is useless in the core of the Internet where you only have

The vendor has no way of knowing if a GE or 10GE link will be used 
between routers or between routers and hosts.

I've not yet heard of a single example of a router which does not 
support Ethernet and in consequence would not need to implement 
Redirect for the abovementioned reason.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 25 Aug 2010 21:11:22 -0400

On Wed, Aug 25, 2010 at 1:06 AM, Pekka Savola <[email-masked]> wrote:
> The vendor has no way of knowing if a GE or 10GE link will be used between
> routers or between routers and hosts.
>
> I've not yet heard of a single example of a router which does not support
> Ethernet and in consequence would not need to implement Redirect for the
> abovementioned reason.

So, back to:
1) should implement redirect
2) should NOT enable by default

right?

---

From: Alain Durand <[email-masked]>
Date: Wed, 25 Aug 2010 19:58:31 -0700

> 2) should NOT enable by default

This is what I'm after.

   - Alain.

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Aug 2010 12:24:46 +0900

>> 2) should NOT enable by default

for juniper's internal network?

randy

---

From: Pekka Savola <[email-masked]>
Date: Thu, 26 Aug 2010 11:03:34 +0300 (EEST)

> 2) should NOT enable by default

No, this is exactly NOT not what I'm saying.  Instead:

1) must implement redirect

I was only responding to point 1), and I have no firm stance on 2).

However I must say that most reasons I've seen for disabling it have 
been rather weak.  For example this and the quoted message sum up a 
'security argument':

http://www.mail-archive.com/[email-masked]/msg25910.html

I'll certainly agree that vendors should expose the default value in 
configuration, no matter what.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 27 Aug 2010 10:00:25 -0500

Alain,

Did you see my email where I asked what kind of a router are you talking
about that cannot implement an IPv6 dinky control plane feature like
Redirect?  MUST implement Redirect by a router makes sense to me.
Unless we know what specific router, what specific router card, and what
specific network interface on the card cannot support Redirect, there is
no case I can see yet for changing MUST implement to SHOULD implement.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alain Durand
Sent: Wednesday, August 25, 2010 10:59 PM
To: Christopher Morrow
Cc: Thomas Narten; deployment prevention; Pekka Savola;
[email-masked]
Subject: Re: Router redirects in Node Requirements document

This is what I'm after.

   - Alain.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 27 Aug 2010 10:00:25 -0500

Alain,

Hemant

-----Original Message-----

This is what I'm after.

   - Alain.

---

From: Jared Mauch <[email-masked]>
Date: Fri, 27 Aug 2010 11:04:49 -0400

> Redirect?  MUST implement Redirect by a router makes sense to me.

Yes, we understand that you see "MUST" as something important here.

> no case I can see yet for changing MUST implement to SHOULD implement.

No, no no, you are missing the point.

Redirects are harmful to the hosts and the routers.

Cisco can't make a router that does them correctly so we had to disable them
for ipv6.  Nothing you can say here will convince me that your BU or any of
the other BUs at cisco will learn to do the right thing.  If Cisco can't get
it right, what hope does a smaller vendor have?

You never responded to my private note to you on this topic, which tells me
understanding and learning from this damage is not part of your role here.

- Jared

---

From: Jared Mauch <[email-masked]>
Date: Fri, 27 Aug 2010 11:04:49 -0400

- Jared