Subject: RE: a concern on bridge-like nd-proxies

From: "Dave Thaler" <[email-masked]>
Date: Wed, 16 Jul 2003 07:32:29 -0700

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-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Jul 2003 17:05:04 +0200

inline...

> 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

---

From: Thomas Narten <[email-masked]>
Date: Tue, 29 Jul 2003 08:46:13 -0400

> Jul 03    Submit Proxy RA to IESG for Proposed Standard.

To be clear, the charter also says:

   o Develop Proxy Router Advertisement solution for prefix
     delegation and publish. This enables a simple site border router
     to
 re-advertise downstream a prefix it hears on its upstream
     link.
 The Multi-Link subnet work will be used as the basis for
     this.
 Note: General multi-link subnet work will be done
     elsewhere
 in the IETF. 

I.e., the charter item is NOT "multi-link subnets". It is a rather
specific subset of multi-link subnets geared (as I understand it) to
the particular problem of wanting to have a /64 assigned to one (e.g.,
P2P link) also be bridged to an attached Ethernet on the other side of
the router.  It is not the full multi-link subnet solution.

Currently, the full-blown multi-link subnet has no home in the
IETF. IMO, finding such a home would likely require a BOF, where the
community has a chance to understand just what the problem is,
applicability, etc. I.e., Pekka raised some valid questions in this
regard earlier in this thread.

The multi-link subnet work also relates to the topic of zerouter, for
which there was one BOF already. See
http://internet.motlabs.com/mailman/listinfo/zerouter (and its
archives) for more info.

http://internet.motlabs.com/pipermail/zerouter/2003-July/000262.html
might also be relevant.

Thomas