netdev - RE: [PATCH 01/01] ipv6: RFC4214 Support (v2.2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDC34@XCH-NW-7V2.nw.nos.boeing.com>
Date:	Thu, 15 Nov 2007 13:59:34 -0800
From:	"Templin, Fred L" <Fred.L.Templin@...ing.com>
To:	YOSHIFUJI Hideaki / 吉藤英明 
	<yoshfuji@...ux-ipv6.org>
Cc:	<netdev@...r.kernel.org>, <vladislav.yasevich@...com>
Subject: RE: [PATCH 01/01] ipv6: RFC4214 Support (v2.2)

Yoshifuji, 

> -----Original Message-----
> From: YOSHIFUJI Hideaki / 吉藤英明 [mailto:yoshfuji@...ux-ipv6.org] 
> Sent: Thursday, November 15, 2007 10:44 AM
> To: Templin, Fred L
> Cc: netdev@...r.kernel.org; vladislav.yasevich@...com; 
> yoshfuji@...ux-ipv6.org
> Subject: Re: [PATCH 01/01] ipv6: RFC4214 Support (v2.2)
> 
> In article 
> <39C363776A4E8C4A94691D2BD9D1C9A1029EDC31@...-NW-7V2.nw.nos.bo
> eing.com> (at Thu, 15 Nov 2007 10:11:16 -0800), "Templin, 
> Fred L" <Fred.L.Templin@...ing.com> says:
> 
> > Yoshifuji, 
> > 
> > > -----Original Message-----
> > > From: YOSHIFUJI Hideaki / 吉藤英明 [mailto:yoshfuji@...ux-ipv6.org] 
> > > Sent: Thursday, November 15, 2007 3:48 AM
> > > To: Templin, Fred L
> > > Cc: netdev@...r.kernel.org; vladislav.yasevich@...com; 
> > > yoshfuji@...ux-ipv6.org
> > > Subject: Re: [PATCH 01/01] ipv6: RFC4214 Support (v2.2)
> > > 
> > > In article 
> > > <39C363776A4E8C4A94691D2BD9D1C9A1029EDC2B@...-NW-7V2.nw.nos.bo
> > > eing.com> (at Wed, 14 Nov 2007 22:44:17 -0800), "Templin, 
> > > Fred L" <Fred.L.Templin@...ing.com> says:
> > > 
> > > > From: Fred L. Templin <fred.l.templin@...ing.com>
> > > > 
> > > > This patch includes support for the Intra-Site Automatic Tunnel
> > > > Addressing Protocol (ISATAP) per RFC4214. It uses the SIT
> > > > module, and is configured using extensions to the "iproute2"
> > > > utility.
> > > > 
> > > > The following diffs are specific to the Linux 2.6.24-rc2 kernel
> > > > distribution. This message includes the full and patchable 
> > > diff text;
> > > > please use this version to apply patches.
> > > > 
> > > > Signed-off-by: Fred L. Templin <fred.l.templin@...ing.com>
> > > 
> > > BTW, how will we handle DNS name (and TTL) and/or multiple PRL entries 
> > > in RFC4214?
> > > 
> > > I'm doubting if we really need to handle PRL refresh in kernel.
> > 
> > DNS name and PRL refresh are done in a daemon that either exec's
> > 'ip' or issues the device ioctl's directly. When there are multiple default
> > router IPv4 addresses, the daemon picks one as the primary and writes
> > it to the kernel. It can then change to a different primary later if it wants
> > to. Also possible is something like VRRP to allow several routers for
> > fault tolerance even though there is only a single default router address. 
> 
> Why?  All PRLs should be installed in kernel so that standard router 
> selection can be used.  For this, I think we should have just one
> isatap interface per set of PRLs provideing virtual link,
> especially if each of them provides the same prefix.

I'm somewhat surprised that you would bring this up at this time, but
let's talk about it. IMHO, there are two types of ISATAP routers; those
that advertise themselves as default in their Router Advertisements
(let's call these "ROUTERS") and those that only advertise more-specific
routes (let's call these "routers"). In a well-maintained site, the former
would consist of all IPv4 addresses returned from a FQDN lookup for
"isatap.example.com" while the latter would consist of all other FQDNs
in the domain "example.com".

So, how would we get the addresses of all ROUTERS into the kernel?
IMHO, not by pumping them in one at a time using "ip". Instead, we
could have an application that sends the RSs and lets the kernel
process the RAs while also getting a copy of the RAs for itself. Is
that what you want? If so, we should probably not be bothering with
the RS/RA pinging for the single ISATAP router at all. What do you
think?

Fred
fred.l.templin@...ing.com

> --yoshfuji
> 
-
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