inline... Dave Thaler wrote: > > 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.
I don't know that there is any other approach except to say "install a router". I hadn't really though about this before yesterday, when you reminded me of issues I was handling operationally more than ten years ago. So yes, I'm arguing for publishing off the standards track (which is either a charter update or an IESG decision, I guess). Brian > > 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] --------------------------------------------------------------------
