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. Brian Pekka Savola wrote: > > Hi, > > I tried to raise this issue in the monday's meeting, but let me try to > augement it a bit. > > 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)? > > - 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..) > > 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) > - supporting multiple routers connected in different branches of the > bridge mesh > - *having to* support SEND in every case (sure, supporting SEND would be > nice but if it's too much bother..) > > 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. > > 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] > -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
