Hi, Dow Street <[EMAIL PROTECTED]> writes:
> On Aug 29, 2007, at 2:51 PM, Arnaud Ebalard wrote: > >> Let's let people that still argue in favor of source-routing prove >> >> - there is a need > > 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). 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. >> - 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? 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. >> - there is a need at L3 to blindly process their pkts > > 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. >> - 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? 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, > which do you think are unable to be mitigated through a revised RH > 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+ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
