> > >-Jail(2) specify "ip_number" and/or "ip6_number" into the kernel.
> >
> > Well, I guess we want it to be "and", right ? Will people want to
> > bind both a IPv4 and IPv6 address (does it make sense to do so ?)
> > or will people only need to bind one of them ?
>
> I also think it is "and", but maybe some time some application
> just use one of them and specify another familiy's addr as
> null. So I used "and/or".
>
> > > What about multiple IPv6 or IPv4 addresses per jail? It might be a
> > > good idea while Inoue-san is at it. Or is this an incredibly stupid
> > > question?
> >
> > I don't know how technically difficult it would be to allow multiple
> > IPv4 and IPv6 addresses per jail, but I can think of a few very good
> > things to do with it. I spend a fair amount of time playing with
> > routing protocols and it would be wonderful to be able to create
> > jailed version of gated/zebra/rodscode on the same box and watch
> > them interact. It would probably cut the size of my hardware lab
> > used for this now in half or maybe even quarter it!
>
> I'm not sure if multiple addrs for each address familiy will
> be useful or not.
Just about anything usefull in a non jailed world is useful in a
jailed world. Other applications for this would be a jailed NAT
router, ability to jail our dual homed DNS and web services where
everything is fully redundant right down to dual nics in every box,
dual switches and 2 IP's on seperate blocks with DNS running on 2
boxes at 4 IP's.
We do things for Telco's and they are really big into redundancy
by dualality, and that means 2 IP's inside a jail, or 2 jails.
>
> But at least, I think several other change(e.g. kernel routing
> table implementation change, or prepare several virtual ones
> on user-land) will also be necessary for several instances of
> each routing protocol implementation to operate on a system.
Your correct, I had not taken that thought far enough to think about
the fact that the kernel routing table is a shared resouce. Is it protected
from modification by a jailed process?
>
> > >-Kernel treat "ip6_number" as just a same kind of extension
> > > for IPv6 as "ip_number" for IPv4.
> >
> > I'm not against them being sockaddr's.
>
> I think it depends on if we allow multiple addrs per address
> family.
>
> If we don't allow it, I think sockaddr is not better, because,
>
> -Need to explicitely forbid multiple same families
> specification(e.g. either of sockaddr is AF_INET) as API.
>
> -Kernel side also need to check (1) case, and do some
> additional work.
> (return error, or prefer the former or the latter)
>
> -When more sockaddr's are added in the future, things will
> be more complicated.
>
> If we allow it(multiple addrs per address family), then I
> think sockaddr list pointer member, and total sockaddr's
> number member should be added, and they are searched in
> prison_ip(), prison_ip6() or such like that in kernel.
>
> But again, I'm not sure how multiple addrs per address family
> is useful.
>
> If explicit needs for "multiple addrs per address family" are
> not clear now, I would like to try to implement just adding
> ip6_number member for this time.
I think that this is probably the best path at this time.
--
Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
