Brian Carpenter writes: > I'd go a bit further. I messed around with a large bridged > network for some years, and this included messing with ARP > proxies and all the troubles they cause. Basically, making > a level 2 device simulate level 3 functions is a kludge, and it > gets even worse when attempting to "bridge" different LAN > technologies. It probably has some failure modes that are very > hard to analyze. > > So while I understand there may be a market for such devices, > I would have very low confidence in our ability to publish > a watertight spec. An informational document would seem > the right way to go, rather than anything that looks like > a standard.
Currently the IPv6 charter has a goal: Jul 03 Submit Proxy RA to IESG for Proposed Standard. While I have no problem with Informational if we do publish the approach, the WG should decide whether it wants to either change the charter, or go with a different approach for PS. It sounds like you (Brian) are arguing for the former. It was also pointed out to me after the meeting that the spanning tree protocol is optional even for L2 bridges, so it ought to be fine for us to say that it's optional here too. > Pekka Savola wrote: > > I have a concern that we're trying to solve all the possible problems > with > > bridge-like ND-proxies. (After all, we're engineers and we like to solve > > the problems..) > > > > But, I think we need to really consider whether we NEED or WANT to solve > > those problems. > > > > - what's the applicability of bridge-like ND-proxy? > > * replace the "(consecutive) simple NAT boxes for home" deployment > > model? > > * a model applicable in scenarios where deploying a router would not > > work > > * an ability to expand a /64 over a few links of different L2 media in > > home (or similar networks) > > * single admin domain/trusted environment (where SEND doesn't matter)? I agree with all of the above except "where SEND doesn't matter", which I would say "where SEND may or may not matter" (depending on the environment). > > - what's the non-applicability of bridge-like ND-proxy? > > * building large ad-hoc networks > > * a mechanism to replace all of your Ethernet switches / bridges > > * a replacement for routers > > > > (probably missed some but..) I agree with these. > > Based on this, I have a very strong gut feeling that we're going into a > > very, very questionable direction if we want to implement e.g.: > > > > - spanning tree protocol (implying at least 3 boxes which are not > > connected in serial) See my response to Brian. The draft discusses it since several folks who attended the Seattle interim meeting provided feedback that they considered it a requirement. > > - supporting multiple routers connected in different branches of the > > bridge mesh Agree this is not a requirement, and at the moment the spec does not support that. I think it is useful to document the limitations that are not met, and they shouldn't be a probably due to the applicability. > > - *having to* support SEND in every case (sure, supporting SEND would > be > > nice but if it's too much bother..) Agree. > > I don't think it's the goal to emulate bridges as closely as possible, > as > > bridges (or Ethernet switches) are generic devices. I don't think we > want > > this to be. I also don't think it's an explicit goal to NOT be generic. Rather this is a feature or lack of feature of any specific approach. What is, however, a nice feature (but not a requirement) is that if someone already implements an ARP proxy, then making it work for IPv6 should not be overly difficult. -Dave > > Of course, we could write a problem statemetn for ND proxies but Im not > > sure it's required. > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
