Subject: New Routing Header!!!

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 28 Aug 2007 18:31:52 +1000

Hi,

Based on feedback from the group, we have written a draft for a new
routing header. The functionality is the same as the RH0. The draft
will soon be posted to the IETF site.

The main differences are:

1. Maximum up to 4 addresses in the header. (the number is based on
the reply I got for the question about the usage scenarios in operator
environments).
2. Only one header in each packet.
3. Firewall policy reccomendation.
4. RPF reccomendation.

Please have a look and let us know your comments.

Thanks,
Vishwas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 28 Aug 2007 11:50:33 +0200

Hi Vishwas, Hi *,

> Please have a look and let us know your comments.

It seems the draft intends to update RFC 2460. Does it imply that RH4
would be mandatory to implement in all IPv6 stacks? It's probably me but
I don't see the point in adding complexity to IPv6 stacks (_all_
implementations shipped), especially when the functionality has already
been proven to have an almost null usefulness.

Below are commented quotes from the draft :

>  The RH4 header has format and functionality similar to the RH0 header
>  without having the major vulnerabilities of the "Routing Header". 

Efforts to get a new RH type defined will certainly require more than
having only major vulnerabilities removed compared to RH0. Having _all_
vulnerabilities mitigated would be more respectful of past discussions
regarding RH0 and time already spent on it.

>  A Routing header is not examined or processed until it reaches the 
>  node identified in the Destination Address field of the IPv6 header.  
>  There can be at most one RH4 header in any packet. A packet with more 
>  than one RH4 header is discarded. This functionality can be
>  implemented in a firewall or any other IPv6 node.

First part of that paragraph states that packets are not checked
en-route but the second part states the opposite (you clearly need to
examine the RH to get the type). The sentence "A packet ... is
discarded" is to vague. Next sentence too.

> 4.  Security Considerations
>
>   The purpose of this document is to add a new type of Routing extension
>   header of IPv6. RH0 has been shown to have undesirable security 
>   implications.
>    
>   Many of the attacks including the amplification attack cannot occur with 
>   the RH4 header. All the addresses in the RH4 header need to be checked with
>   the firewall policy to make sure the firewall is able to trap packets meant 
>   for addresses in the firewall policy and take relevent action.
>
>   Whereever possible, including the administrative network edge, RPF check 
>   needs to be done.

"Many of the attacks ... ": unlike in the IPv6 specification, the
security assessment of the mechanism (threats, impacts, mitigation)
should be done to describe what remains. 

"All the addresses need ...": what does it mean precisely ?

"Whereever possible, ...": this is a common statement. What's the
precise purpose? What if it is not done (i.e. impact in that case)?

After a first reading of the draft, my main feeling is that the
functionality is not precisely defined because the intended use is not
clearly stated: the purpose does not seem to be the addition of something
which would serve some categories of users. It's more oriented towards
the limited reduction of the level of threat associated with RH0 in
order to make it "acceptable". It's adding complexity without
considering the real need (if any).

The problem of the processing (by nodes, routers, both, default policy)
is not clearly covered. This was a problem in 2460. Who should implement
that? Will your IPv6-enabled Mobile phone have that "feature"?

Ability to source-route a packet is basically the ability to "coerce" a
remote node to send traffic towards a specific destination. In MIPv6,
final destination in RH2 (HoA) is always locally available on the
targeted node (the one the packet is sent to using the CoA). And before
a node even sends traffic to a CoA, the proof of ownership of the
address by the peer has always been made, i.e. to be able to have
someone follow you in that direction, you have to prove your ownership
of the targeted address, which is precisely your ability to _both_
receive/emit traffic at/from that address.

Having intermediate waypoints (i.e. 4 addresses) while keeping the same
level of protection as the one provided by RH2 for the Internet
infrastructure is IMHO not so easily feasible.

IMHO, you should:

 - assess the real use of your new RH (context, scope, purpose)
 - see the needs in term of checks, limitation, filtering
 - define the mechanism based on generic RH
 - check against all previously described threats (available in
   reference documents)
 - see what remains in terms of threats and impacts against the IPv6
   infrastructure and if it is worth the trouble.

A general question I have on the topic is the following: is the ability
to "bypass" anycast routing scheme considered a problem or is it ok? I'd
like to hear on that point from people that use that kind of setup for
protection against DoS in large scale deployment (DNS servers, 6to4
relay routers, ...).

Regards,

a+

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 28 Aug 2007 20:23:05 +1000

Hi Arnaud,

> been proven to have an almost null usefulness.
Yes, the intent is to update RFC2460 and implies its a mandatory to
implement functionality. I had thought the same too, but if you see a
past thread, I did get use cases for the RH4 functionality.

> regarding RH0 and time already spent on it.
I agree. Well in my view, we have to see what is practically possible,
and can be done without overloading the router CPU. We intend to go as
far as we can with this. In my view this is the initial version of the
draft and we do intend to update the draft as we move forward.

> discarded" is to vague. Next sentence too.
I guess the point I am trying to make is the algorithm given below
should only be implemented by the destination node, however the
discarding of malicious packets can be done by a firewall. I will
clarify the text for the same.

> "All the addresses need ...": what does it mean precisely ?
I mean the IPv6 addresses included in the routing header - RH4.

> precise purpose? What if it is not done (i.e. impact in that case)?
Well the idea is RPF check cannot be done, in all scenarios. The
simple case is that routing over the internet is asymmetric, and RPF
checks cannot be applied. However such checks can be made at the edge
of the networks.

>    infrastructure and if it is worth the trouble.
I agree. Infact if you see the mails from me on the list that is the
direction I have taken. I have asked questions on what are real use
scenarios for the same.

I will update the draft based on comments from you. this draft is
there to spur a discussion on the subject.

Thanks a lot for your comments,
Vishwas

---

From: Christian Huitema <[email-masked]>
Date: Tue, 28 Aug 2007 07:27:33 -0700

Before we invent a new header, have we looked at ways were the current
legitimate usage could be solved by dedicated applications? Something in
the spirit of traceroute, maybe with a little cooperation from the
involved players in the spirit of UDP echo? Specialized applications
open a much smaller attack surface than an IPv6 layer mechanism. They
are also easier to secure using end-to-end mechanisms.

-- Christian Huitema

---

From: Thomas Narten <[email-masked]>
Date: Wed, 29 Aug 2007 10:08:40 -0400

Sorry to interrupt, but I'd suggest that working on a new RH design is
mostly a waste of time at this point.

Can we please _first_ identify a user/customer for a proposed RH, so
we are sure we actually design something useful? And at the same time
be sure we have a transition strategy for getting it
implemented/deployed that makes sense (i.e., doesn't require upgrading
parts of the infrastructure outside of the control of those wanting to
take advantage of the RH?)

I.e., exactly what _real_ problem are we trying to solve here?

The idea that we can define something (with no clear expected use) and
get it actually implemented and deployed is mostly naive. (My guess is
this would be an _optional_ standard, and vendors mostly wouldn't
bother to implement it -- if no one actually needs it).

One can argue that the whole RH0 debacle results from designing
functionality for which there was no clear customer/use. Time and time
again, this sort of protocol design results in (at best) wasted
effort.

Thomas

---

From: sengottuvelan srirangan <[email-masked]>
Date: Wed, 29 Aug 2007 10:24:32 -0700 (PDT)

Hi Viswas,
   
  I could not get the below comments in the draft:
   
  "
  A Routing header is not examined or processed until it reaches the node identified in the Destination Address field of the IPv6 header.
 
   There can be at most one RH4 header in any packet. A packet with
 more   than one RH4 header is discarded. This functionality can be
 implemented  in a firewall or any other IPv6 node.
  :
  :
   Whereever possible, including the administrative network edge, RPF
 check needs to be done.
  "
   
  I have following comments on the draft:
   
  1.  Draft recommends to implement the stack in  the destination nodes but also says , Whereever possible,including the administrative network edge, RPF check needs to be done. This functionality can be  implemented  in a firewall or any other IPv6 node. 
  please clarify.
   
  2. What if current IPv6 node receives RH4 header?. How do we handle the RH4 header in the current implementaions? 

  Regards
  Sengottuvelan

Vishwas Manral <[email-masked]> wrote:
  Hi,

Thanks,
Vishwas

Network Working Group V. Manral
Internet-Draft M. Dutta
Updates: 2460, 4294 IP Infusion Inc.
(if approved) 
Intended status: Standards Track 
Expires: February 28, 2008 
August 28, 2007

New IPv6 Type 4 Routing Header
draft-manral-ipv6-rh4-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on December 28, 2007.

Copyright Notice

Copyright (C) The IETF Trust (2007).

Abstract

The functionality provided by IPv6's Type 0 Routing Header can be
exploited in order to achieve traffic amplification over a remote
path for the purposes of generating denial-of-service traffic. 

This document updates the IPv6 specification to the use of a new 
IPv6 Type 4 Routing Header, in light of this security concern. This 
new header provides the same functionality of the Routing Header
Type-0, while taking care of the major security concerns defined 
in the draft [draft-ietf-ipv6-deprecate-rh0-01].

Manral Expires February 28, 2008 [Page 1]

Internet-Draft New IPv6 Type 4 Routing Header June 2007

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Format of RH4 . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10

Manral Expires February 28, 2008 [Page 2]

Internet-Draft New IPv6 Type 4 Routing Header June 2007

1. Introduction

[RFC2460] defines an IPv6 extension header called "Routing Header",
identified by a Next Header value of 43 in the immediately preceding
header. A particular Routing Header subtype denoted as "Type 0" is
also defined. Type 0 Routing Headers are referred to as "RH0" in
this document.

128-fold amplification of data traffic can result using the IPv6 
amplification attack as defined in [I-D.ietf-ipv6-deprecate-rh0-01].
This attack is particularly serious in that it affects the entire
path between the two exploited nodes, not only the nodes themselves
or their local networks. 

The draft [I-D.ietf-ipv6-deprecate-rh0-01] deprecates the use of the 
RH0 header. However operators use and require the functionality provided
by the RH0 header.

This draft defines the Routing Header of Type-4, and referred to as "RH4" 
header. The RH4 header has format and functionality similar to the RH0 
header without having the major vulnerabilities of the "Routing Header".

This document updates [RFC2460] and [RFC4294].

Manral Expires February 28, 2008 [Page 3]

Internet-Draft New IPv6 Type 4 Routing Header June 2007

2. Definitions

RH4 in this document denotes the IPv6 Extension Header type 43
("Routing Header") variant 4 ("Type 4 Routing Header"), is a type of 
Routing header as defined in [RFC2460]. 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

3. Format of RH4

The Type 4 Routing header has the following format (it is the same as 
the RH0 header except for the limit on the "Hdr Ext Len" field. Some 
additional restrictions and checks have been added):

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type=0| Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[1] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[2] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Address[n] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Next Header 8-bit selector. Identifies the type of header
immediately following the Routing header. Uses
the same values as the IPv4 Protocol field
[RFC-1700 et seq.].

Hdr Ext Len 8-bit unsigned integer. Length of the Routing
header in 8-octet units, not including the first
8 octets. For the Type 4 Routing header, Hdr
Ext Len is equal to two times the number of
addresses in the header. The maximum value of this
field can be 8. That means a maximum of 4 addresses
can be added to the Routing Header.

Manral Expires February 28, 2008 [Page 4]

Internet-Draft New IPv6 Type 4 Routing Header June 2007

Routing Type 4.

Segments Left 8-bit unsigned integer. Number of route
segments remaining, i.e., number of explicitly
listed intermediate nodes still to be visited
before reaching the final destination.

Reserved 32-bit reserved field. Initialized to zero for
transmission; ignored on reception.

Address[1..n] Vector of 128-bit addresses, numbered 1 to n. The
maximum value of n is 4. 

Multicast addresses or Link Local Unicast address must not appear in a 
Routing header of Type 4, or in the IPv6 Destination Address field of 
a packet carrying a Routing header of Type 4. 

A Routing header is not examined or processed until it reaches the
node identified in the Destination Address field of the IPv6 header. 
There can be at most one RH4 header in any packet. A packet with more
than one RH4 header is discarded. This functionality can be implemented 
in a firewall or any other IPv6 node.

In that node, dispatching on the Next Header field of the immediately
preceding header causes the Routing header module to be invoked,
which, in the case of Routing Type 4, performs the algorithm which is 
similar to the as specified in section 4.4 of [RFC2460]:

Manral Expires February 28, 2008 [Page 5]

Internet-Draft New IPv6 Type 4 Routing Header June 2007

if Segments Left = 0 {
proceed to process the next header in the packet, whose type is
identified by the Next Header field in the Routing header
}
else if Hdr Ext Len is odd {
send an ICMP Parameter Problem, Code 0, message to the Source
Address, pointing to the Hdr Ext Len field, and discard the
packet
}
else {
compute n, the number of addresses in the Routing header, by
dividing Hdr Ext Len by 2

if Segments Left is greater than n or n is greater than 4 {
send an ICMP Parameter Problem, Code 0, message to the Source
Address, pointing to the Segments Left field, and discard the
packet
}
else {
decrement Segments Left by 1;
compute i, the index of the next address to be visited in
the address vector, by subtracting Segments Left from n

if Address [i] or the IPv6 Destination Address is multicast 
or link local unicast address {
discard the packet
}
else {
Compare the addresses in the Routing Header to check that 
none of the address belong to the routers self address

if overlapping address exist {
discard the packet
}

swap the IPv6 Destination Address and Address[i]

if the IPv6 Hop Limit is less than or equal to 1 {
send an ICMP Time Exceeded -- Hop Limit Exceeded in
Transit message to the Source Address and discard the
packet
}
else {
decrement the Hop Limit by 1

resubmit the packet to the IPv6 module for transmission
to the new destination
}
}
}
}

Manral Expires February 28, 2008 [Page 6]

Internet-Draft New IPv6 Type 4 Routing Header June 2007

5. IANA Considerations

The IANA registry "Internet Protocol Version 6 (IPv6) Parameters"
should be updated to reflect that variant 4 of IPv6 header-type 43
("Routing Header") is added.

7. Acknowlegements

This document benefits from the contributions of many IPV6 and V6OPS
working group participants, including Chris Morrow, Tony Hain, Jinmei
Tatuya and Brian Carpenter.

8. References

8.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

Manral Expires February 28, 2008 [Page 7]

Internet-Draft New IPv6 Type 4 Routing Header June 2007

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.

[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006.

8.2. Informative References

[CanSecWest07]
BIONDI, P. and A. EBALARD, "IPv6 Routing Header Security",
CanSecWest Security Conference 2007, April 2007.

http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf

[I-D.ietf-v6ops-security-overview]
Davies, E., "IPv6 Transition/Co-existence Security
Considerations", draft-ietf-v6ops-security-overview-06
(work in progress), October 2006.

[I-D.savola-ipv6-rh-ha-security]
Savola, P., "Security of IPv6 Routing Header and Home
Address Options", draft-savola-ipv6-rh-ha-security-02
(work in progress), March 2002.

[I-D.savola-ipv6-rh-hosts]
Savola, P., "Note about Routing Header Processing on IPv6
Hosts", draft-savola-ipv6-rh-hosts-00 (work in progress),
February 2002.

[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.

[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.

[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.

Appendix A. Change History

This section to be removed prior to publication.

Manral Expires February 28, 2008 [Page 8]

Internet-Draft New IPv6 Type 4 Routing Header June 2007

Authors' Addresses

Vishwas Manral
IP Infusion Inc,
Bamankhola
Bansgali
Almora - Uttaranchal
Phone: +91 98456 61911
Email: [email-masked]

Manoj Dutta
IP Infusion Inc,
125, S. Market Street,
San Jose, CA
Phone: 408 794 1500
Email: [email-masked]

Manral Expires February 28, 2008 [Page 9]

Internet-Draft New IPv6 Type 4 Routing Header June 2007

Full Copyright Statement

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
[email-masked].

Acknowledgment

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).

Manral Expires February 28, 2008 [Page 10]

       
---------------------------------
Pinpoint customers who are looking for what you sell.

---

From: Jason Schiller <[email-masked]>
Date: Wed, 29 Aug 2007 14:08:52 -0400 (EDT)

On Wed, 29 Aug 2007, sengottuvelan srirangan wrote:

>   1.  Draft recommends to implement the stack in  the destination nodes
>   but also says , Whereever possible,including the administrative
>   network edge, RPF check needs to be done. This functionality can be
>   2. What if current IPv6 node receives RH4 header?. How do we handle
>   the RH4 header in the current implementaions? 
>    
>    

One of the poblems with the current implementation of RH0 (and IPv4 source
routed packets) is when packet transits a router that is not one of the
source routed hops, it must specially process the packet.  In otherword
forward the packet in software.

Take Host A in the diagram below who wants to send traffic to Host E, but
prefers the packet to first visit Router D.

--------   ----------   ----------   --------
|Host A|---|Router B|---|Router C|---|Host E|
--------   ----------   ----------   --------
                 \        /
                  \      /
                 ---------- 
                 |Router D|
                 ----------

Host A will build a packet with a source address of A, a destination
address of D, and loose source hops of D and E.

When this packet reaches Router B which is not the destination of the
packet, the traffic should be forwarded as normal (in hardware) based on
the destination of the packet D.

When the packet arrives at Router D, then special processing must occur to
support source routing.

The problem that someone else pointed out was there is a conflicting
requirement to apply firewall filters that match on destination address,
to also be capable to match on destinations listed in the loose source
hops.  This will likely require special handeling (i.e. packet not
forwarded in hardware).  One approach is to make both of these options
configurable.

I think possibly the problem is that there is confusion about how source
routing affects routers, and how it affects hosts.  Routers generally
carry lots of transit traffic (not destined for the local router) and
hosts do not.  In this case (where the host is not acting as a router),
the packet should always have a desination of the host.  The host
receiving a packet that has some other destination would likely only
result from a misconfigured network.  I suspect the right action in this
case is to drop the packet.

__Jason

---

From: Dow Street <[email-masked]>
Date: Wed, 29 Aug 2007 11:11:27 -0700

It is interesting to me that folks have described locator-identifier  
split as a *real* problem and source routing as a waste of time.  As  
I understand it, one driver for recent loc-id work is a concern over  
routing system scalability (# of DFZ RIB entries).  In the current  
routing model, if a multi-homed site wants to influence how their  
packets are delivered, it will often advertise multiple, more- 
specific prefixes to different peers (leveraging LPM for TE  
purposes).  Unfortunately, this approach drives a cost in the global  
routing system for which most of the nodes (in that global system)  
receive little or no benefit.  Sites are forced to do this indirect  
signaling of their routing interests through BGP because there is no  
explicit method for directing traffic over a particular path / link.   
This is precisely what source-routing gives you - an explicit method  
for signaling path preference, and it does so in a manner that  
(potentially) allows the costs to be better localized to the  
beneficiaries, rather than incurred by everyone.  I do not claim that  
the current specification or use of RH0 / RH4 is a complete solution,  
but I think it is incorrect to assume loc-id split and source routing  
are completely unrelated.

In my opinion, the RH4 draft appears to be heading in the right  
direction:

1.  Maintains a *general* source routing functionality in IPv6
2.  Makes it required functionality in IPv6 implementations

As others have mentioned (or perhaps decided not to mention), source  
routing has the potential to disrupt the current pricing / billing  
model.  I also think, though, that the use(s) of source routing and  
any corresponding evolution of pricing / billing models would be  
difficult to craft / predict outside the operational network.  This  
is one reason why I support a general source routing function that  
allows for some flexibility, rather than one specifically tailored to  
a single purpose.  Many people seemed to think RH0 provided too much  
flexibility - as I understand it, the RH4 proposal attempts to reduce  
the degree of flexibility (i.e. power) to a more acceptable level.

 From my (naive?) vantage point, maintaining source routing as a  
mandatory part of the spec will help to get the functionality into  
implementations *before* a demonstrated (profitable) use case.  In  
other words, we create an environment where innovation is possible,  
and provide a general capability.  IP seems to be the right place in  
the stack to deal with packet delivery and path selection.  If  
implementers are already visiting code to remove RH0, it seems like a  
reasonable time to add something like RH4.  Given the functional  
similarity of RH0 and RH4, it may be more a code edit than "tear out  
old, add new."

I agree that the cost to uninterested parties should be minimized -  
this issue probably needs to be considered at both the node level and  
the network (ISP) level:

Node level impacts -

The RH4 draft provides some guidance in this area, but perhaps it  
could be expanded.  Some thoughts:

Transit nodes (routers):  if the current destination address does not  
match one of your addresses, don't process the routing header

Destination nodes:  if the current destination address does match one  
of your addresses and there is a source routing header, but you do  
not have source routing enabled, drop the packet.

We may want to make a distinction between intermediate and final  
destinations - not sure.  Perhaps nodes that are only ever IPv6 hosts  
do not need the functionality to act as an intermediate destination,  
but should still accept source routed packets if they are the final  
destination.  In any case, clear implementation guidance should  
eliminate a number of the problems voiced over RH0.

Network level impacts -

Another concern raised about source routing is its potential to make  
traffic (trend) prediction more difficult, which would threaten the  
existing ISP pricing / billing model.  This concern seems to be  
fairly easy to mitigate, however.  By reducing the number of  
intermediate destinations, RH4 significantly reduces the degree of  
traffic variability resulting from oscillation DOS events (i.e. "bad"  
variability).

For traffic variability due to "legitimate" uses of source routing,  
upstream providers can simply adjust their billing model.  Returning  
to the previous example -

A - B -- C - D

If A and D want to support source routing for their customers, but B  
and C are concerned over traffic predictability, they (B and C) can  
charge A and D a higher rate.  i.e. "if your (A) traffic patterns are  
less predictable, it makes our (B) statistical capacity planning more  
difficult so we must charge you more."  If the number of source  
routed packets is low, the impact to capacity planning should be  
low.  As the number of source routed packets increases, the impact to  
capacity planning may also increase.  However, if source routing were  
to become more widely used, it may well be due to its usefulness to  
the end-user.  In this case, it is reasonable the end-user would be  
willing to pay a bit more to A for source routing service, which  
could offset the additional cost of A's connection to B.  Since the  
source route is visible in the IP header (even when encrypted), it is  
easy to enforce policy - i.e. drop the packet.

I'm sure it is more complicated than this, so I'd be interested in  
hearing from folks familiar more with the ISP / business side.

R,
Dow

---

From: Jari Arkko <[email-masked]>
Date: Wed, 29 Aug 2007 21:16:47 +0300

What Thomas says below is valid. We need to know
what problem or purpose we are building a new
safe RHx for. Once that is known, we can evaluate
if your design meets the goals, ensure that the
problem is of general interest for the Internet community
that it makes sense to recommend it be implemented,
etc.

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Aug 2007 08:04:24 +1200

On 2007-08-30 02:08, Thomas Narten wrote:
> Can we please _first_ identify a user/customer for a proposed RH, 

I agree. A use case draft should be the first step.

Incidentally, RFC 2460 is clear that unknown headers should cause the
packet to be dropped, so the transition strategy is tricky in any case.

    If, as a result of processing a header, a node is required to proceed
    to the next header but the Next Header value in the current header is
    unrecognized by the node, it should discard the packet and send an
    ICMP Parameter Problem message to the source of the packet, with an
    ICMP Code value of 1 ("unrecognized Next Header type encountered")
    and the ICMP Pointer field containing the offset of the unrecognized
    value within the original packet.

     Brian

> so

---

From: David Conrad <[email-masked]>
Date: Wed, 29 Aug 2007 13:14:40 -0700

Hi,

> packet to be dropped, so the transition strategy is tricky in any  

Water under the bridge and all that, but I'm curious: what was the  
rationale for this?  It would seem to imply it is impossible to do  
incremental deployment of new headers, and thus essentially freezes  
routing header development for the lifetime of IPv6.

Am I misunderstanding?

Thanks,
-drc

---

From: Thomas Narten <[email-masked]>
Date: Wed, 29 Aug 2007 16:30:09 -0400

Hi David.

> routing header development for the lifetime of IPv6.

The way routing headers work in IPv6, the next destination in the
routing header gets placed into the destination field of the base IPv6
packet. Thus, the packet itself (because of the routing header) is
addressed to the router in question. If that router doesn't understand
how to process it (i.e., presumably to place the next address into the
destination field -- after doing whatever other processing is
appropriate), there isn't much it can do other than drop it. Same as
any other node receiving a packet addressed to it that it doesn't know
how to handle.

The benefit of this design (compared with IPv4) is that intermediate
routers do no need to inspect packets containing routing headers,
unless the router is the actual destination. In IPv4, every router has
to look at the option, including routers that don't do anything as a
result of looking at the routing option...

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Aug 2007 08:30:46 +1200

> routing header development for the lifetime of IPv6.

I just looked this up in 2460 myself, and I'm jet lagged so I may
be confused, but indeed this seems to make it very hard to deploy any
new header except as a fork-lift upgrade among consenting systems.

    Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 29 Aug 2007 16:35:41 -0400

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> 

Problem is, I have no trouble seeing uses for RH0, or whatever new
scheme takes its place. The only problems I've seen mentioned repeatedly
are the potential for DOS attacks in ISP nets.

But ISP nets are not the only application for IPv6.

So why don't ISPs simply filter out any RH0 traffic from their edge
gateways, and leave it at that? And the rest of us can still make use of
this tool, with no change required to RFC 2460.

As always, there are workarounds like MPLS, if RH0 is eliminated. I'm
having a hard time understanding why edge router filters don't work
infinitely better than a mod to RFC 2460.

Bert

---

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 29 Aug 2007 23:51:35 +0200

Hi Brian, Hi guys,

> new header except as a fork-lift upgrade among consenting systems.

End-to-End. [with the deprecation of RH0,] IPv6 packets will flow from
the source to the destination found in the IPv6 header, where the
specific implementation will have the context and the code to analyse
(filter) it and understand it (process the tiny details of the headers
and upper layer).

This leaves a simple work for the core: find the best path from the
source to the destination, i.e. route the packet based on the content of
IPv6 header destination address. End hosts then stack functionalities
on top of that. The most low level (i.e. most demanding) functionalities
start working in extension headers (MIPv6, ...)

If someone comes with a _real_ need for having the core network
providing help outside an efficient routing of its traffic to a specific
destination, it will find help to make it happen but that's not the
purpose of IP. 

Let's let people that still argue in favor of source-routing prove

- there is a need
- there is a need at L3
- there is a need at L3 to blindly process their pkts
- there is a need at L3 to blindly process their pkts and it's safe

And yes, deprecation removes blind source routing from IP stacks and
leaves little room for having it coming back.

Regards,

a+

---

From: Dow Street <[email-masked]>
Date: Wed, 29 Aug 2007 16:33:49 -0700

> Let's let people that still argue in favor of source-routing prove

I see advertisement of specifics by multi-homed sites as a indication  
that they desire more control over how their traffic is routed.  If  
the architecture does not address that problem directly, I think it  
is likely to manifest itself indirectly at some other place (e.g. the  
RIB growth problem).

> - there is a need at L3

IP seems to be the right place in the stack to deal with issues of  
path selection and packet delivery.  Do you see a better place in a  
different layer?

> - there is a need at L3 to blindly process their pkts

Can you clarify what you mean by "blindly"?  As others have stated,  
including support for source routing in IPv6 does not necessarily  
mean that every IPv6 node in the network needs to be configured as a  
viable (intermediate) source routing destination.  I agree that a  
goal of the new draft should be to minimize the cost to uninterested  
nodes.

> - there is a need at L3 to blindly process their pkts and it's safe

Also, please clarify "safe".  Is this a question on the acceptable  
range of traffic (trend) variability?  Of the issues raised at csw07,  
which do you think are unable to be mitigated through a revised RH  
specification?  In your opinion, which issues are currently  
unmitigated in the RH4 draft?

Thanks,
Dow

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 30 Aug 2007 10:57:05 +1000

Hi Thomas,

Thanks a lot for your very kind comments.

> mostly a waste of time at this point.
I understand your point completely. It sounds very logical to have a
use case before going in for a draft, which otherwise may not even be
required.

However it seems you have probably not followed mails I have sending
carefully enough. I have raised this issue on the list way back and
got some feed back too. I have found based on feedback the main uses
of the RH header to be Explicit Traffic Engineering as well as for OAM
purposes (something the IETF has underplayed for a long time). There
is a paper by Geoff Huston (I am not totally sure it was him), that
gives some use cases for operators.

I am ok, adding a section at the beginning of the draft for the same.

> again, this sort of protocol design results in (at best) wasted
Having been the one to have identified the amplification attacks
around a couple of years ago, I realize the problems and related
security issues. However I am not sure of how you say there are no use
cases. I got the information asking that very question on the list. It
would be great if you can let me know what you base your assumptions
on?

Thanks,
Vishwas

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 30 Aug 2007 11:03:57 +1000

Hi Velan,

I agree things are a bit confusing.

The idea however is very simple. A routing header is looked at only by
the node identified as the destination address in the IPv6 packet, so
the processing algorithm is to be done only on those nodes. A
firewall, any other middlebox, or even routers that do deep packet
processing (its done in a lot of ASIC's right now at line-rate) can
drop packets when they see discrepancies as identified in the draft
below.

The answer of how to process an unrecognized Routing Header is given
in page 12-13 of RFC2460. Do have a look and let me know if things are
clearer.

Thanks,
Vishwas

On 8/30/07, sengottuvelan srirangan <[email-masked]> wrote:
> A Routing header is not examined or processed until it reaches the node
> identified in the Destination Address field of the IPv6 header.
>
> 1.  Draft recommends to implement the stack in  the destination nodes but
> also says , Whereever possible,including the administrative network edge,
> RPF check needs to be done. This functionality can be  implemented  in a
> firewall or any other IPv6 node.
> please clarify.
>
> Administrative Requests:
> https://www1.ietf.org/mailman/listinfo/ipv6
>  ________________________________

---

From: Thomas Narten <[email-masked]>
Date: Wed, 29 Aug 2007 21:34:56 -0400

> As always, there are workarounds like MPLS, if RH0 is eliminated. 

I don't get this at all.  RH is end to end (i.e., it's part of the IP
header, and presumably added by the originating device and processed
by the ultimate destination). MPLS, on the other hand, is an L2
technology and does not involve either the original sender or the
ultimate destination (normally).

I see them providing completely different services and NOT being
interchangable in any real sense.

Thomas

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 30 Aug 2007 11:43:15 +1000

Hi Thomas,

I guess Bert's comparison comes from the fact we can decide the path a
packet takes, just like we can for MPLS. So if the Path Computation
Element(PCE) calculated a path using CSPF that had loops(and ence
signalled using RSVP-TE), a similar situation could arise.

However I disagree with Bert here. The difference is that MPLS is
connection oriented in nature. The path setup element(RSVP-TE or
management for T-MPLS) and the data packets are different flow. It
would require to at least hack the head end router to get a simialr
functionality. Besides off-path attacks will be harder to make.

Thanks,
Vishwas

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 30 Aug 2007 11:46:41 +1000

Hi Dave,

The text for processing an unknown Routing Header is attached from
RFC2460. It is another matter that a new header may not be able to
traverse the Firewall and such packets may be dropped.

   If, while processing a received packet, a node encounters a Routing
   header with an unrecognized Routing Type value, the required behavior
   of the node depends on the value of the Segments Left field, as
   follows:

      If Segments Left is zero, the node must ignore the Routing header
      and proceed to process the next header in the packet, whose type
      is identified by the Next Header field in the Routing header.

      If Segments Left is non-zero, the node must discard the packet and
      send an ICMP Parameter Problem, Code 0, message to the packet's
      Source Address, pointing to the unrecognized Routing Type.

   If, after processing a Routing header of a received packet, an
   intermediate node determines that the packet is to be forwarded onto
   a link whose link MTU is less than the size of the packet, the node
   must discard the packet and send an ICMP Packet Too Big message to
   the packet's Source Address.

Thanks,
Vishwas

---

From: Geoff Huston <[email-masked]>
Date: Thu, 30 Aug 2007 17:25:20 +1000

>    value within the original packet.

So are you _really_ sure you want to drop RH0 from the IPv6 protocol 
spec, given that the practicalities of a general use 'replacement' 
header is going to present some fascinating transition issues?

Geoff

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 30 Aug 2007 09:31:15 +0200

Hi,

> is likely to manifest itself indirectly at some other place (e.g. the

Operators won't help, for valid reasons, all the more when there are
protocols that have already shown great results (sorry for using MIPv6
as an example again) without even modifying the routing in the core.

The underlying problem is always the same: id and locator roles of IPv6
addresses. IMHO, if the people that specifically work on multi-homing
have a clean and safe solution that requires some mandatory extension in
IPv6 specification, IPv6 WG will be happy to consider that. Now, adding
RH4 in the spec for the fun of it in the hope that it will serve some
purpose in the future simply seems weird.

> path selection and packet delivery.  Do you see a better place in a

If you need something working at a large scale, which creates a
_precise_ rationale to have that included at L3, it is the place and
SHOULD be put there. 

Now, if there is only a limited rationale, it COULD be put there but as
an external feature (i.e. outside 2460), to be deployed by people that
have the need. 

In other cases, their is no need for that to be at L3.

> Can you clarify what you mean by "blindly"? 

What 2460 specifies for routers regarding RH0 processing and what
vendors had implemented (before the deprecation). I don't consider the
amplification here (i.e. even a limited version of RH0 with only one
address in it, processed by default by routers, fits my description).

> As others have stated, including support for source routing in IPv6
> does not necessarily mean that every IPv6 node in the network needs to
> be configured as a viable (intermediate) source routing destination.

I hope so. 

> I agree that a goal of the new draft should be to minimize the cost to
> uninterested nodes.

Minimizing the cost will be done by answering the question: "Is that
feature so useful that it should be in IPv6 specification?". i.e. need
vs. cost.

> range of traffic (trend) variability? 

It's a question of all threats that make the internet less safe and add
useless code in stacks, increasing the attack surface. 

Less than 1 year ago, you could kill the routers of a well-known vendor
on the IPv6 internet with one single RH0 packet (per router),
i.e. collapse the core network in few seconds/packets.

One can blame the vendor but it will object with 2460-compliance ...

> Of the issues raised at csw07,
> specification?  

None. They can all be mitigated. Best proof is RH2 (and associated
conditions of use) ...

> In your opinion, which issues are currently unmitigated in the RH4
> draft? 

... because MIPv6 designers have first defined a use, have then defined
the associated mechanism with security in mind (Do no harm to the
existing internet). 

Sorry, but i won't answer your question on non-mitigated issues of RH4
till its use is clarified and i see an interest (i.e. potential users).

Regards,

a+

---

From: Ignatios Souvatzis <[email-masked]>
Date: Thu, 30 Aug 2007 10:46:58 +0200

>    value within the original packet.

Yes, but this would only be the node addressed by the IPv6 header - or 
do I read this wrongly? So the core of the network is not affected either
way (unless explicit filtering is implemented somewhere), and only
routers of end networks that wish to participate in, say, a future RH4
routing would need to upgrade the software.

	-is

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 30 Aug 2007 21:39:32 +1000

Hi Ignatious,

Quoting the RFC2460:

   With one exception, of Hop-by-hop extension headers are not examined
   or processed by any node along a packet's delivery path, until the packet
   reaches the node (or each of the set of nodes, in the case of multicast)
   identified in the Destination Address field of the IPv6 header.

So in a way you are right, but again it we may want to test the
routing path from any router in the network to any other router in the
network.

Thanks,
Vishwas

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 Aug 2007 14:50:30 +0300

> header is going to present some fascinating transition issues?

I suspect code changes are necessary in any case, completely
independent of whether RH0 or RHx is going to be employed
or what the IETF does.

First, given the possibility for amplification, implementations
would be well advised to at least add some checks and limits
on RH0, even if it would not be deprecated. Second, a number
of implementations already have turned the feature off, which
obviously means that we cannot expect a random node in the
Internet to always respect anyone's request to perform a RH0
operation.

But, at the end of the day, I'm not sure the above is a big
problem.

Please remember that RH works in an end-to-end fashion;
only the source and current destination of the packet needs to
process it. Not routers in between.

There have been examples where new RH types
have been specified, implemented, and used. In Mobile IPv6,
for instance, RH2 is implemented by the participants. This
is easy, as only the participants need to implement it,
and RH2 is a MUST-to-implement in the specifications
for any of the participant nodes in Mobile IPv6.

More generally, if one wants to provide a new feature based
on routing header, what we need is

- Implementation in nodes that want to use RHx for something.
  This should be easy.

- Implementation in other, consenting nodes that appear in
  a non-final destination of the routing header.

  This is not needed in all cases, e.g., not in the Mobile Ipv6
  case.

The second item is harder, but I'm not sure its an unreasonable
requirement. After all, as a manager of a network you probably
want to be in control of where re-forwarding to a new address
is used. And you probably are in control of that, already...

Jari

---

From: Ignatios Souvatzis <[email-masked]>
Date: Thu, 30 Aug 2007 14:00:57 +0200

> routing path from any router in the network to any other router in the

Well, if those routers aren't *your* routers, I'm afraid you'll need
the owners' coöperation to the extend that they install RH4-capable 
firmware.

Not much different from the IPv4 situation, I guess?

	-is

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 30 Aug 2007 22:45:24 +1000

Hi Ignatious,

You are right, however it will depend on what uses such
implementations are used for. As such a routing header is end-to-end.

That said another thing to keep in mind is that the situation is no
different to adding some new feature to IPv6, with the advantage that
the behavior in case the RH4 header is not recognized by a node is
well defined.

Thanks,
Vishwas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 30 Aug 2007 08:53:29 -0400

> gives some use cases for operators.

What I mean by "find a use" or "find a customer", is not to point to
some generic, hand-wavy "it would be nice" from some third party. It
is to get the customer/user who has a real problem to solve to come
and explain what that problem is, so we can talk about about how to
solve it. Anything short of that risks development of a solution  in
search of a problem. The IETF has a lot of experience with that, and
it is mostly negative.

It's easy to find _possible_ uses. What we should be looking for is a
problem that needs solving, for which a routing header really is a
good/best solution, not just a "cool" or "neat" solution.

> would be great if you can let me know what you base your assumptions

RH0 has been part of IPv6 for more than a decade. Remind of _who_ has
used it or is using it, and what critical applications take advantage
of it. I believe the answer to the question is pretty much the empty
set. That is what I mean there being "no use cases".

Thomas

---

From: Dow Street <[email-masked]>
Date: Thu, 30 Aug 2007 09:38:15 -0700

> an external feature (i.e. outside 2460), to be deployed by people that

<snip>

> address in it, processed by default by routers, fits my description).

Are you primarily concerned with making / keeping source routing a  
*mandatory* component of IPv6 because you see this as adding attack  
vectors at every IPv6 node?

I suppose I see these as separable:

- making the functionality mandatory is to help get it into  
implementations so that interested users / operators have source  
routing as a tool.
- this does not mean (to me) that the functionality to act as an  
intermediate source routing destination (routers and/or hosts) must  
be enabled by default.  I think this question is worth discussing.

It probably also makes sense to consider architectural and  
implementation issues separately:

Architectural:  I think this is our primary area to address in any  
new RHx draft.  As I understand it, RH4 directly addresses the  
architectural issue of RH0 that was of most concern to the group -  
the number of intermediate way-points.

Implementation:  A new RHx draft can probably provide better  
implementation guidance than was present for RH0, helping to reduce  
the number of implementation problems.  I don't think concern over  
implementation problems is a valid reason for eliminating source  
routing altogether.

There also appears to be a wider philosophical debate going on (among  
list participants) over general vs. specific functionality, and the  
type of network we think the Internet should be.  Should the Internet  
be a collection of specific mechanisms, each oriented toward a known,  
narrow, and demonstrably profitable use?  Or should the Internet  
architecture (whatever that is) provide a set of general tools that  
can be used in a variety of ways?  As IETF standards go, you don't  
get much more "architectural" than IP.

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 30 Aug 2007 19:20:12 +0200

Hi,

> vectors at every IPv6 node?

No, that's not my primary concern. My primary concern is the addition of
_proven_ useless and complicated functionalities in a fundamental part
of our communication infrastructure.

> be enabled by default.  I think this question is worth discussing.

As soon as you have a _precise_ use and expected users for that, sure,
i'll continue the discussion. Now, i let Thomas and Itojun keep asking
for concrete uses. I consider i have already spent enough time asking
many times the same simple questions without getting any precise
answer:  

                 Who will use it? How? What for?

Regards,

a+

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 30 Aug 2007 13:42:41 -0400

> From: Jari Arkko [mailto:[email-masked]] 

> Second, a number

There are other examples of this that have not caused the protocol to be
deprecated. One obvious example would be multicast. Another example is
TELNET. Another is directed broadcast. These continue to be very useful
protocols, at least the first two are, as far as I'm concerned, even
though I wouldn't expect any random ISP node to support them.

If anything, I'd advocate what has to be the easiest solution. Leave RH0
and RFC 2460 as is, turn RH0 off by default, allow ISPs to drop RH0
packets at edges (as they do now for other valid protocols anyway), and
go ahead with RH4 or other better ideas, if there's demand for it.

Bert

---

From: Dow Street <[email-masked]>
Date: Thu, 30 Aug 2007 13:15:04 -0700

>                  Who will use it? How? What for?

In your opinion, is it sufficient to describe potential uses of an  
IPv6 source routing mechanism?  Or is it also necessary to have the  
commitment of a large organization / commercial entity who intends to  
deploy IPv6 source routing in a specific timeframe and according to a  
specific use?  There is no intended sarcasm imbedded in this question  
- I think it is a real and valid question which partly determines how  
innovation can occur in the Internet.

I have been advocating a mechanism that is general and allows for a  
variety of potential uses.  This is the nature of RH0 - and I see  
RH4 / RHx as the "safer" replacement for RH0.  In your opinion, is  
this an acceptable approach, or would you only support a RHx that is  
tailored to a specific use case?

Thanks,
Dow

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Aug 2007 08:31:44 +1200

On 2007-08-30 20:46, Ignatios Souvatzis wrote:
> do I read this wrongly? 

Correct ... and actually I quoted the wrong text for the case of an
unknown RH number, but the result is the same - only the next-hop
router listed in the RH itself needs to understand that new RH number.
But that does create a 'consenting adults' situation; if you construct
an RHx you must know that every router listed in it understands RHx,
otherwise the packet will be dropped. That is quite a restriction on
deployment scenarios beyond experimental or local use.

     Brian

> So the core of the network is not affected either

---

From: Dow Street <[email-masked]>
Date: Thu, 30 Aug 2007 14:32:27 -0700

On Aug 30, 2007, at 1:31 PM, Brian E Carpenter wrote:

>> Yes, but this would only be the node addressed by the IPv6 header  
>> - or do I read this wrongly?
>

Maybe this isn't a huge problem.  For source routing to be  
particularly useful, the sender probably wants / needs to know  
something about the topology.  At a minimum, the sender would  
presumably need to know the addresses of the way-points to use in the  
source route.  Whatever mechanism / process is used to determine  
these way-points could probably verify RHx support (at those  
addresses) with just a little more work.

R,
Dow

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 30 Aug 2007 23:40:32 +0200

Hi,

Dow Street <[email-masked]> writes:

> specific use? 

No. IMHO, if someone comes with a good idea and other people find it
useful and want to have that in their laptop/network/pda/phone ... it
seems you have support and should start working on it.

In that particular case, people put the most powerful source routing
mechanism in the specification, which then got implemented on all
routers and even some hosts. 

During the _huge_ threads after CanSecWest during the discussions on the
ietf ML, we asked many times if someone had a use or had already used
it. 

I can remember one person who knew someone that uses the mechanism for
some firewalling stuff (correct me if i'm wrong). I don't remember if I
asked about the tools that allowed to use RH0: I know only ping6 and
scapy6 (again, correction appreciated). 

What i try to show is that the mechanism has been _proven_ useless by a
past decade of full availability: you can bearly find users and tools
(at least on IETF IPv6 WG ML). 

> There is no intended sarcasm imbedded in this question

Someone has a _good_ idea, code it / specify it. If it's real innovation
or useful enough, it gets an audience. Otherwise, it remains only an RFC
#, or some useless piece of undebugged code in millions of network
stacks.

> variety of potential uses....

... which have not already been discovered during last decade.

> In your opinion, is  this an acceptable approach, or would you only
> support a RHx that is tailored to a specific use case?

For me, you are adding a sword to a chirurgical toolkit, in the hope
that it will be sharp enough to be used for some purpose in the
future. I just don't see the point.

You asked for my opinion, so it's just that. 

Regards,

a+

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Aug 2007 10:12:25 +1200

Dow,

Fortunately, Bill Fenner thought things through when drafting
RFC 4727 (Experimental Values in Headers):

"3.6.  IPv6 Routing Header Routing Type

    This document assigns two values for the Routing Type field in the
    IPv6 Routing Header, 253 and 254."

So, people wanting to work on a new RH type can develop
use cases and run experiments using these values, without
further IETF action. These values are fine in a 'consenting
adults' situation if unmodified nodes implement the RFC 2460
rules correctly.

    Brian

On 2007-08-31 09:32, Dow Street wrote:
>>> Yes, but this would only be the node addressed by the IPv6 header - 
>>> or do I read this wrongly?
>>
> Maybe this isn't a huge problem.  For source routing to be particularly 
> useful, the sender probably wants / needs to know something about the 
> topology.  At a minimum, the sender would presumably need to know the 
> addresses of the way-points to use in the source route.  Whatever 
> mechanism / process is used to determine these way-points could probably 
> verify RHx support (at those addresses) with just a little more work.
> 
> R,
> Dow
>

---

From: Dow Street <[email-masked]>
Date: Thu, 30 Aug 2007 17:15:26 -0700

> seems you have support and should start working on it.

Is that "no" to the first or second question?

> routers and even some hosts.

Do you mean the case of RH0?

> (at least on IETF IPv6 WG ML).

RH0 may have been fully available from the perspective of IPv6  
implementations, but given the limited deployment of IPv6, I don't  
think lack of current use is *proof* that IPv6 RH0 is not useful, or  
would not be useful in the future.

R,
Dow

---

From: Dow Street <[email-masked]>
Date: Thu, 30 Aug 2007 17:55:28 -0700

> adults' situation if unmodified nodes implement the RFC 2460

Thanks, Brian.  This is a good point, and I think it raises a few  
important questions for the group:

- What bounds are placed on the achievable source routing  
functionality if only consenting nodes participate, and all other  
nodes simply forward (without processing) or drop?  I don't have a  
clear idea on this yet.

- If a "consenting nodes only" model is adopted, is any arbitrary  
behavior by those consenting nodes deemed acceptable by the non- 
consenting nodes?  Previous discussions seemed to indicate that at  
least some folks would answer "no" to this question.

In other words, how is using RH 253 between consenting nodes (allowed  
to behave arbitrarily) any different than allowing consenting nodes  
to run RH0, and non-consenting nodes disabling RH0?  One difference  
(cynical hat on) is that opponents of source routing now force  
proponents to get new functionality implemented and deployed - only  
to have the same debate a few years from now when it comes time to  
standardize the functionality.

Do I have this right?

R,
Dow

---

From: Stig Venaas <[email-masked]>
Date: Fri, 31 Aug 2007 03:58:54 +0200

Thomas Narten wrote:
[...]
> set. That is what I mean there being "no use cases".

I'm not arguing for keeping source routing here, but one quite useful
thing it can be used for is traceroute. You can for instance trace from
a remote point in the network towards yourself. This can be very helpful
when debugging routing problems.

Stig

---

From: [email-masked] (Arnaud Ebalard)
Date: Fri, 31 Aug 2007 09:35:51 +0200

Hi,

> Is that "no" to the first or second question?

Respectively, the answers are "necessary" and "no".

> Do you mean the case of RH0?

Yes.

> would not be useful in the future.

It's not useful, it's funny and dangerous, hence the deprecation. At
some point, you will probably come to the conclusion that having a
source routing mechanism that does not potentially hinder others
requires that (at the very least) :

1) The forwarding routers trust you for providing them a new target
   (destination) for the packet and are ok spending time in slow path
   doing that.

2) The destination is ok with receiving source-routed traffic: note that
   this is not what 2460 mandates (i.e. RH* extension header with 0
   value in segleft should simply be skipped to process the next
   header, w.r.t. the specification). But this is how serious people
   handle RH0 (and future RH* traffic) on end entities (except for
   those for which you have a local need, like RH2 or yours).
   
   Best example is what the ISC has done for F Root DNS instances: try
   and send requests to them including RH0. It will be dropped.

As a conclusion, having RH* deployed requires to have _processing_ of
RH* performed by consenting routers, and that the packets end up on a
consenting host. The other routers will simply forward traffic based on
IPv6 header content. Other hosts will simply drop the traffic. (Please,
note the use of hosts and routers in previous sentences).

And yes, this limits your ability to bounce your traffic on every router
in the internet but this will obviously be the case (if not already
from threads on v6ops) as soon as operators get their IPv6 BCP in sync
with the IPv4 ones, i.e. as soon as "no ipv6 source route" is the
default or is forced by admins. 

Cheers,

a+

---

From: Jari Arkko <[email-masked]>
Date: Fri, 31 Aug 2007 12:22:51 +0300

Dow,

> behavior by those consenting nodes deemed acceptable by the
> non-consenting nodes?  Previous discussions seemed to indicate that at
> to behave arbitrarily) any different than allowing consenting nodes to
> run RH0, and non-consenting nodes disabling RH0?  One difference
> proponents to get new functionality implemented and deployed - only to
> have the same debate a few years from now when it comes time to
I think any proposal for special re-forwarding to new destination,
based on RH0, RHx, or anything else would have to be evaluated
by its merits. Some of the questions that would be asked in
review include, for instance, how is consent obtained from
the participants obtained, and how can the consenting nodes
ensure that they are not used as part of an attack (e.g.,
amplification).

Jari

---

From: Dow Street <[email-masked]>
Date: Fri, 31 Aug 2007 08:11:39 -0700

> ensure that they are not used as part of an attack (e.g.,

Thanks, Jari.

I was also speaking mostly about the functional aspects of the  
mechanism, not the policy aspect.  I suppose when the IETF publishes  
an RFC (or decides not to deprecate one), it essentially 1. endorses  
the described functionality and 2. implies that potentially negative  
consequences that could arise if the functionality were widely  
deployed have been considered.  Using RH 253 among consenting nodes  
allows the IETF as a body to remain silent on the merits and  
potentially negative consequences of that particular mechanism /  
use.  That is a difference.

Of course, in this case the deprecation of RH0 essentially  
establishes a position on both RH0 and sufficiently similar  
functionality.  It is sort of like case law, with the RH0 deprecation  
draft as the legal opinion.  I think this is partly why folks were so  
interested that the text in the RH0 deprecation draft focus on the  
single issue of most concern (e.g. oscillation DoS), rather than the  
merits of source routing in general.

Is this consistent with your thinking?

Thanks,
Dow

---

From: bill fumerola <[email-masked]>
Date: Fri, 31 Aug 2007 12:18:48 -0700

> when debugging routing problems.

engineers also can use it when setting up, debugging, or for periodic
testing of peering sessions to make sure that the other side isn't doing
anything against the contractual terms of the peer (e.g. overriding the
normal policies that result from standard RIB->FIB route selection).

examples:
http://ptd.mbo.ma.rcn.net/peerinfo/

All peers are requested to enable LSRR on router interfaces facing RCN
peering sessions to facilitate network diagnostics at least during session
activation.

http://www.via.net/support/support_peer.html 
We require that our peers permit LSR, loose source routing, at least at the border.

http://www.noc.wiscnet.net/peering/
We require that our peers permit LSR, loose source routing, at least at
the border for diagnostic purposes.

i don't have an ACM account, but:
http://portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=1016718

without comparable functionality in IPv6, we lose a feature actively in
use (through IPv4) by some networks for verification of proper peering.

if i'm out of touch with current policies on peering & LSRR, please let
me know. sure, diehards of the end-to-end principle certainly believe
that removing source routing is an assult on said principle[1]. there
are other uses for source routing in some form, beyond e2e, that is
helpful.

-- bill

1. http://www.postel.org/pipermail/end2end-interest/2007-May/006711.html