[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDBF5@XCH-NW-7V2.nw.nos.boeing.com>
Date: Wed, 7 Nov 2007 11:12:47 -0800
From: "Templin, Fred L" <Fred.L.Templin@...ing.com>
To: "Stephen Hemminger" <shemminger@...ux-foundation.org>
Cc: YOSHIFUJI Hideaki / 吉藤英明
<yoshfuji@...ux-ipv6.org>, <netdev@...r.kernel.org>
Subject: RE: [PATCH 04/05] ipv6: RFC4214 Support
> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@...ux-foundation.org]
> Sent: Wednesday, November 07, 2007 10:45 AM
> To: Templin, Fred L
> Cc: YOSHIFUJI Hideaki / 吉藤英明; netdev@...r.kernel.org
> Subject: Re: [PATCH 04/05] ipv6: RFC4214 Support
>
> On Wed, 7 Nov 2007 10:41:49 -0800
> "Templin, Fred L" <Fred.L.Templin@...ing.com> wrote:
>
> > Yoshifuji,
> >
> > > -----Original Message-----
> > > From: YOSHIFUJI Hideaki / 吉藤英明 [mailto:yoshfuji@...ux-ipv6.org]
> > > Sent: Wednesday, November 07, 2007 10:37 AM
> > > To: Templin, Fred L
> > > Cc: netdev@...r.kernel.org; yoshfuji@...ux-ipv6.org
> > > Subject: Re: [PATCH 04/05] ipv6: RFC4214 Support
> > >
> > > Hello.
> > >
> > > In article
> > > <39C363776A4E8C4A94691D2BD9D1C9A1029EDBE5@...-NW-7V2.nw.nos.bo
> > > eing.com> (at Tue, 6 Nov 2007 17:16:11 -0800), "Templin, Fred
> > > L" <Fred.L.Templin@...ing.com> says:
> > >
> > > > @@ -154,6 +155,14 @@ static struct ip_tunnel * ipip6_tunnel_l
> > > > struct net_device *dev;
> > > > char name[IFNAMSIZ];
> > > >
> > > > +#if defined(CONFIG_IPV6_ISATAP)
> > > > + /* ISATAP (RFC4214) - router address in daddr */
> > > > + if (!strncmp(parms->name, "isatap", 6)) {
> > > > + parms->i_key = parms->iph.daddr;
> > > > + parms->iph.daddr = remote = 0;
> > > > + }
> > > > +#endif
> > > > +
> > > > for (tp = __ipip6_bucket(parms); (t = *tp) != NULL; tp =
> > > > &t->next) {
> > > > if (local == t->parms.iph.saddr && remote ==
> > > > t->parms.iph.daddr)
> > > > return t;
> > >
> > > I do not think it is a good idea to change the behavior based on
> > > the interface name.
> >
> > The goal was to avoid requiring changes to applications such as
> > 'iproute2', i.e., the intention was for a standalone code
> insertion point
> > within the kernel itself. What do you suggest?
>
> Agreed, magic names are evil.
>
> Change iproute2 utilities, if it is more logical for administration.
This being an experimental release, I would prefer to go
forward with a standalone kernel solution for the first
iteration then come back with the iproute2 changes at a
later time. IMHO, we should only touch iproute2 once, and
it should be an architected solution - not just a quick
hack. For the short term, timeliness of interoperability testing
with the other major OS's should be the highest priority, IMHO.
Other opinions?
Fred
fred.l.templin@...ing.com
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists