Activating "ip6.forwarding" and "accept_rtadv" at the same time

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Activating "ip6.forwarding" and "accept_rtadv" at the same time

Simon Comeau Martel-2
Hi,

I am trying to figure out why OpenBSD won't let me activate
"net.inet6.ip6.accept_rtadv" and "net.inet6.ip6.forwarding" at the same
time.

My ISP started an IPv6 beta, and I am trying to configure my OpenBSD router
for it. I want to get the IPv6 address of my gateway (the address of my
ISP's router) on my pppoe0 interface via resold and to run rtadvd on my lan
interface, so my hosts can configure themselves.

What's the clean way to get that working? For now, I disabled ip6.forwarding
in sysctl.conf and didn't enable rtadvd in rc.conf.local. That way, 'rtsold'
starts and works correctly. Then, I added "sysctl
net.inet6.ip6.forwarding=1" and "/usr/sbin/rtadvd <LAN INTERFACE>" to
/etc/rc.local

Everything works fine that way (as far as I can tell, for now), but it
doesn't feel clean...

Thanks for your help

--
Simon Comeau Martel
[hidden email]
https://comeau.info

Reply | Threaded
Open this post in threaded view
|

Re: Activating "ip6.forwarding" and "accept_rtadv" at the same time

Martin Pelikan
2010/9/5, Simon Comeau Martel <[hidden email]>:
> I am trying to figure out why OpenBSD won't let me activate
> "net.inet6.ip6.accept_rtadv" and "net.inet6.ip6.forwarding" at the same
> time.

/usr/src/sys/netinet6/in6_proto.c:int   ip6_accept_rtadv = 0;   /*
enabling forwarding and rtadv concurrently is dangerous */

> My ISP started an IPv6 beta, and I am trying to configure my OpenBSD router
> for it. I want to get the IPv6 address of my gateway (the address of my
> ISP's router) on my pppoe0 interface via resold and to run rtadvd on my lan
> interface, so my hosts can configure themselves.

I can't think of a reason why two ISP's can't configure their routers'
IPs manually. IMO autoconf is for end-users only.
--
Martin Pelikan

Reply | Threaded
Open this post in threaded view
|

Re: Activating "ip6.forwarding" and "accept_rtadv" at the same time

Simon Comeau Martel-2
2010/9/5 Martin Pelikan <[hidden email]>

>
> I can't think of a reason why two ISP's can't configure their routers'
> IPs manually. IMO autoconf is for end-users only.



I am an end-user; not an ISP. I need autoconf to find what's my IPv6 default
gateway. And I need to have a router on my LAN telling my devices how to
configure themselves. Or am I missing something? Is the only "clean"
solution to statically configure my default route on my OpenBSD router? I
can't really do that; since my ISP assume I would be using autoconf to find
it, it could change at any time...

Just to make sure things are clear, I have bean given by my ISP a /64 for my
router interface, and a /56 for my LAN.


Would I need to configure two OpenBSD boxes? One establishing the PPPOE
connection to my ISP with autoconf, and the other one with rtadvd running.
(With static routes between the two OpenBSD boxes). That would be somewhat
overkill...

Thanks

--
Simon Comeau Martel
[hidden email]
https://comeau.info

Reply | Threaded
Open this post in threaded view
|

Re: Activating "ip6.forwarding" and "accept_rtadv" at the same time

Paul de Weerd
On Sun, Sep 05, 2010 at 02:14:20PM -0400, Simon Comeau Martel wrote:
| 2010/9/5 Martin Pelikan <[hidden email]>
|
| >
| > I can't think of a reason why two ISP's can't configure their routers'
| > IPs manually. IMO autoconf is for end-users only.
|
|
|
| I am an end-user; not an ISP. I need autoconf to find what's my IPv6 default
| gateway. And I need to have a router on my LAN telling my devices how to
| configure themselves. Or am I missing something? Is the only "clean"
| solution to statically configure my default route on my OpenBSD router? I
| can't really do that; since my ISP assume I would be using autoconf to find
| it, it could change at any time...
|
| Just to make sure things are clear, I have bean given by my ISP a /64 for my
| router interface, and a /56 for my LAN.

You received a /64 for your router interface ?  Or are you in a /64
subnet with other customers ?  The setup sounds weird to me.  To what
address is your ISP forwarding that /56 ?

| Would I need to configure two OpenBSD boxes? One establishing the PPPOE
| connection to my ISP with autoconf, and the other one with rtadvd running.
| (With static routes between the two OpenBSD boxes). That would be somewhat
| overkill...

That would still require forwarding on the machine doing autoconf...

Paul 'WEiRD' de Weerd

--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.undeadly.org                 

Reply | Threaded
Open this post in threaded view
|

Re: Activating "ip6.forwarding" and "accept_rtadv" at the same time

Simon Comeau Martel-2
On Sun, Sep 5, 2010 at 3:23 PM, Paul de Weerd <[hidden email]> wrote:

> You received a /64 for your router interface ?  Or are you in a /64
> subnet with other customers ?  The setup sounds weird to me.  To what
> address is your ISP forwarding that /56 ?
>

Yeah, it's a bit strange. But it's their IPv6 beta; very few customers are
in it right now. I guess they won't give so much address space in the long
run. Right now, they give a /64 subnet to everyone in the beta, and, if you
tell them you will use a router (that's the case for everyone except those
who only have one PC connected directly to their ADSL modem), they also give
you a /56 subnet. They are all publicly routable IPv6 addresses.


>
> | Would I need to configure two OpenBSD boxes? One establishing the PPPOE
> | connection to my ISP with autoconf, and the other one with rtadvd
> running.
> | (With static routes between the two OpenBSD boxes). That would be
> somewhat
> | overkill...
>
> That would still require forwarding on the machine doing autoconf...
>

That's right. I typed to fast.

--
Simon Comeau Martel
[hidden email]
https://comeau.info

Reply | Threaded
Open this post in threaded view
|

Re: Activating "ip6.forwarding" and "accept_rtadv" at the same time

Josh Hoppes
I'm pretty sure IPv6 forwarding and accepting routing advertisements
will be a necessity going forward. At the current time I don't know of
any other way to dynamically find the default route in IPv6, necessary
for end user gateways on consumer ISPs. Even using DHCPv6 your default
gateway is found only via routing advertisements, and they have added
the Prefix Delegation option to DHCPv6 to provide end user gateways
with their address space, DHCP will take care of providing the ISP
their forwarding information at that point.

This is all based on what I've seen discussed and read myself, if I've
misunderstood something speak up.

On Sun, Sep 5, 2010 at 2:49 PM, Simon Comeau Martel <[hidden email]>
wrote:

> On Sun, Sep 5, 2010 at 3:23 PM, Paul de Weerd <[hidden email]> wrote:
>
>> You received a /64 for your router interface ?  Or are you in a /64
>> subnet with other customers ?  The setup sounds weird to me.  To what
>> address is your ISP forwarding that /56 ?
>>
>
> Yeah, it's a bit strange. But it's their IPv6 beta; very few customers are
> in it right now. I guess they won't give so much address space in the long
> run. Right now, they give a /64 subnet to everyone in the beta, and, if you
> tell them you will use a router (that's the case for everyone except those
> who only have one PC connected directly to their ADSL modem), they also
give

> you a /56 subnet. They are all publicly routable IPv6 addresses.
>
>
>>
>> | Would I need to configure two OpenBSD boxes? One establishing the PPPOE
>> | connection to my ISP with autoconf, and the other one with rtadvd
>> running.
>> | (With static routes between the two OpenBSD boxes). That would be
>> somewhat
>> | overkill...
>>
>> That would still require forwarding on the machine doing autoconf...
>>
>
> That's right. I typed to fast.
>
> --
> Simon Comeau Martel
> [hidden email]
> https://comeau.info

Reply | Threaded
Open this post in threaded view
|

Re: Activating "ip6.forwarding" and "accept_rtadv" at the same time

Olivier Mehani
In reply to this post by Simon Comeau Martel-2
On Sun, Sep 05, 2010 at 03:49:43PM -0400, Simon Comeau Martel wrote:
> > You received a /64 for your router interface ?  Or are you in a /64
> > subnet with other customers ?  The setup sounds weird to me.  To what
> > address is your ISP forwarding that /56 ?
> Yeah, it's a bit strange. But it's their IPv6 beta; very few customers are
> in it right now. I guess they won't give so much address space in the long
> run.

Well, supposedly, end-users should receive /48s from their ISPs [0].

> Right now, they give a /64 subnet to everyone in the beta, and, if you
> tell them you will use a router (that's the case for everyone except those
> who only have one PC connected directly to their ADSL modem), they also
give
> you a /56 subnet.

Back to your initial problem, it is a bit of a bummer. The same happens
with Linux as well. As has been stated before, it is accepted that
router discovery is for end-hosts only. I still don't quite understand
how it is be dangerous (apart from some really twisted cases).

Anyway, maybe you should ask your ISP to implement DHCPv6. DHCP used to
be a client configuration tool, but DHCPv6 is more specifically designed
for router configuration. My ISP does that over a PPP link, and it works
wonderfully.

> They are all publicly routable IPv6 addresses.

And it will stay like that! That's one of the reasons to use IPv6: no
*(&#$(# NAT.

[0] http://tools.ietf.org/html/3769

--
Olivier Mehani <[hidden email]>
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE  F5F9 F012 A6E2 98C6 6655

[demime 1.01d removed an attachment of type application/pgp-signature]

Reply | Threaded
Open this post in threaded view
|

Re: Activating "ip6.forwarding" and "accept_rtadv" at the same time

Claudio Jeker
On Mon, Sep 06, 2010 at 11:18:57AM +1000, Olivier Mehani wrote:

> On Sun, Sep 05, 2010 at 03:49:43PM -0400, Simon Comeau Martel wrote:
> > > You received a /64 for your router interface ?  Or are you in a /64
> > > subnet with other customers ?  The setup sounds weird to me.  To what
> > > address is your ISP forwarding that /56 ?
> > Yeah, it's a bit strange. But it's their IPv6 beta; very few customers are
> > in it right now. I guess they won't give so much address space in the long
> > run.
>
> Well, supposedly, end-users should receive /48s from their ISPs [0].
>

ah, great. So we just have 16 bits more then IPv4. Actually ISP can
provide whatever they like to customers. Residential customers will most
probably end up with /64.

> > Right now, they give a /64 subnet to everyone in the beta, and, if you
> > tell them you will use a router (that's the case for everyone except those
> > who only have one PC connected directly to their ADSL modem), they also
> give
> > you a /56 subnet.
>
> Back to your initial problem, it is a bit of a bummer. The same happens
> with Linux as well. As has been stated before, it is accepted that
> router discovery is for end-hosts only. I still don't quite understand
> how it is be dangerous (apart from some really twisted cases).
>

IIRC it is actually forced by one of the great RFC. Accepting rtadv on a
system with more then one interface is a common cause for routing loops.
Especially since the acceptance can not be limited to an interface.

> Anyway, maybe you should ask your ISP to implement DHCPv6. DHCP used to
> be a client configuration tool, but DHCPv6 is more specifically designed
> for router configuration. My ISP does that over a PPP link, and it works
> wonderfully.
 
I have seen the following ways to solve this a) static gateway IPs and
static routing, b) RIPng, c) gif tunnels and d) ppp.

> > They are all publicly routable IPv6 addresses.
>
> And it will stay like that! That's one of the reasons to use IPv6: no
> *(&#$(# NAT.
>

Actually that's the reason why organizations are not adopting IPv6. NAT is
less evil then IPv6.

--
:wq Claudio

Reply | Threaded
Open this post in threaded view
|

Re: Activating "ip6.forwarding" and "accept_rtadv" at the same time

Toni Mueller-10
In reply to this post by Olivier Mehani
Hi,

On Mon, 06.09.2010 at 11:18:57 +1000, Olivier Mehani <[hidden email]> wrote:
> On Sun, Sep 05, 2010 at 03:49:43PM -0400, Simon Comeau Martel wrote:
> > > You received a /64 for your router interface ?  Or are you in a /64
> > > subnet with other customers ?  The setup sounds weird to me.  To what
> > > address is your ISP forwarding that /56 ?
> > Yeah, it's a bit strange. But it's their IPv6 beta; very few customers are
> > in it right now. I guess they won't give so much address space in the long
> > run.
>
> Well, supposedly, end-users should receive /48s from their ISPs [0].

the rules seem to have changed in the meantime, at least in Europe:

http://www.ripe.net/ripe/docs/ipv6-policy.html#assignment_size


Kind regards,
--Toni++

Reply | Threaded
Open this post in threaded view
|

Re: Activating "ip6.forwarding" and "accept_rtadv" at the same time

Martin Pelikan
In reply to this post by Claudio Jeker
On Mon, Sep 06, 2010 at 09:14:25AM +0200, Claudio Jeker wrote:
> ah, great. So we just have 16 bits more then IPv4. Actually ISP can
> provide whatever they like to customers. Residential customers will most
> probably end up with /64.

exactly, /64 is more than enough
 
> IIRC it is actually forced by one of the great RFC. Accepting rtadv on a
> system with more then one interface is a common cause for routing loops.
> Especially since the acceptance can not be limited to an interface.

I also thought so, but couldn't find it. Maybe we confused it with
host/router differences in ability of following ICMP redirects, which is
the same for IPv4 and v6 - host can, router must not. Or are you able to
find the reference?
I'm a bit afraid of touching the code before being sure that enabling
rtadv on a router is a safe thing. RFC 4861 in section 6.2.7 enables the
router to accept RAs and act upon it. I don't think loop detection would
be too difficult, but it's probably a lot of work to make a button for
this per interface.

> I have seen the following ways to solve this a) static gateway IPs and
> static routing,

exactly.

> > > They are all publicly routable IPv6 addresses.
> > And it will stay like that! That's one of the reasons to use IPv6: no
> > *(&#$(# NAT.
> Actually that's the reason why organizations are not adopting IPv6. NAT is
> less evil then IPv6.

Why do you think so? Most people are refering to security reasons, but it
just equals to "block in" or "block in from any to $my_net"...

--
Martin Pelikan

Reply | Threaded
Open this post in threaded view
|

Re: Activating "ip6.forwarding" and "accept_rtadv" at the same time

Claudio Jeker
On Mon, Sep 06, 2010 at 06:49:46PM +0200, Martin Pelikan wrote:
> On Mon, Sep 06, 2010 at 09:14:25AM +0200, Claudio Jeker wrote:
> > ah, great. So we just have 16 bits more then IPv4. Actually ISP can
> > provide whatever they like to customers. Residential customers will most
> > probably end up with /64.
>
> exactly, /64 is more than enough
>  

Only if you plan to use NAT in the near future. /64 is like a /32 in IP.
Not enough in most cases.

> > IIRC it is actually forced by one of the great RFC. Accepting rtadv on a
> > system with more then one interface is a common cause for routing loops.
> > Especially since the acceptance can not be limited to an interface.
>
> I also thought so, but couldn't find it. Maybe we confused it with
> host/router differences in ability of following ICMP redirects, which is
> the same for IPv4 and v6 - host can, router must not. Or are you able to
> find the reference?
> I'm a bit afraid of touching the code before being sure that enabling
> rtadv on a router is a safe thing. RFC 4861 in section 6.2.7 enables the
> router to accept RAs and act upon it. I don't think loop detection would
> be too difficult, but it's probably a lot of work to make a button for
> this per interface.
>

A per interface rtadv switch was actually planned. Having it global is
stupid. The problem is that in the ivory tower end user systems only have
one interface and only routers have more then one interface. The reality
is a bit different.

> > I have seen the following ways to solve this a) static gateway IPs and
> > static routing,
>
> exactly.
>
> > > > They are all publicly routable IPv6 addresses.
> > > And it will stay like that! That's one of the reasons to use IPv6: no
> > > *(&#$(# NAT.
> > Actually that's the reason why organizations are not adopting IPv6. NAT is
> > less evil then IPv6.
>
> Why do you think so? Most people are refering to security reasons, but it
> just equals to "block in" or "block in from any to $my_net"...
>

NAT is a much simpler concept than IPv6. IPv6 was built to make live as
complex as possible for little or no gain.

--
:wq Claudio

Reply | Threaded
Open this post in threaded view
|

Re: Activating "ip6.forwarding" and "accept_rtadv" at the same time

Rod Whitworth-3
On Mon, 6 Sep 2010 23:26:09 +0200, Claudio Jeker wrote:

>> exactly, /64 is more than enough
>>  
>
>Only if you plan to use NAT in the near future. /64 is like a /32 in IP.
>Not enough in most cases.

Gee, I thought that 18446744073709551616 addresses was a bit more than
1
;-)
*** NOTE *** Please DO NOT CC me. I <am> subscribed to the list.
Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou.

Rod/
---
This life is not the real thing.
It is not even in Beta.
If it was, then OpenBSD would already have a man page for it.

Reply | Threaded
Open this post in threaded view
|

Re: Activating "ip6.forwarding" and "accept_rtadv" at the same time

Martin Pelikan
In reply to this post by Claudio Jeker
2010/9/6, Claudio Jeker <[hidden email]>:
> Only if you plan to use NAT in the near future. /64 is like a /32 in IP.
> Not enough in most cases.

Why? You can always use DHCPv6 and split the rank further... I haven't
much studied the protocol itself, but in practice the only system that
has trouble with it is Linux due to insufficient kernel-userland
interaction - passing of autonomous flag in RA to dhcp6 client. That
is obviously a design fault and is only a matter of time before it
gets straight (whichever way they choose).

> A per interface rtadv switch was actually planned. Having it global is
> stupid. The problem is that in the ivory tower end user systems only have
> one interface and only routers have more then one interface. The reality
> is a bit different.

How would it look like? New ifconfig parameter?

> NAT is a much simpler concept than IPv6.

I have to agree with that. But in long term, many companies need
better solution than multiple NATs and NAT to multiple addresses under
heavy load. So why not rewrite it from scratch (and hope not to make
the same mistakes again)...

Any particular feature that shows the unnecessary complexity? (no
flame, if you want to continue to discuss, I'd be glad off list)
--
Martin Pelikan

Reply | Threaded
Open this post in threaded view
|

Re: Activating "ip6.forwarding" and "accept_rtadv" at the same time

Claudio Jeker
On Tue, Sep 07, 2010 at 10:23:19AM +0200, Martin Pelikan wrote:

> 2010/9/6, Claudio Jeker <[hidden email]>:
> > Only if you plan to use NAT in the near future. /64 is like a /32 in IP.
> > Not enough in most cases.
>
> Why? You can always use DHCPv6 and split the rank further... I haven't
> much studied the protocol itself, but in practice the only system that
> has trouble with it is Linux due to insufficient kernel-userland
> interaction - passing of autonomous flag in RA to dhcp6 client. That
> is obviously a design fault and is only a matter of time before it
> gets straight (whichever way they choose).

As soon as you spilt a /64 into something smaler you left IPv6 land end
entered something that looks like IPv6 but isn't. Sure it is possible but
by doing it you make every IPv6 disciple scream in agony (which is
probably a good thing anyway).

Sure a /64 is a bit more then a /32 since a /64 represents one single LAN
compared to a single address but in the end it is far less then 2^64 IPs.

>
> > A per interface rtadv switch was actually planned. Having it global is
> > stupid. The problem is that in the ivory tower end user systems only have
> > one interface and only routers have more then one interface. The reality
> > is a bit different.
>
> How would it look like? New ifconfig parameter?
>

That was the plan.

> > NAT is a much simpler concept than IPv6.
>
> I have to agree with that. But in long term, many companies need
> better solution than multiple NATs and NAT to multiple addresses under
> heavy load. So why not rewrite it from scratch (and hope not to make
> the same mistakes again)...
>

In some cases companies could run without the double and tripple NAT but
the don't want it. It is a requirement for them. Reality is different then
the IPv6 theory and this is slowly recognized.

> Any particular feature that shows the unnecessary complexity? (no
> flame, if you want to continue to discuss, I'd be glad off list)

I think the number 1 question I have about IPv6 is:
What is wrong with arp?
and maybe as an alternation
Why rely so massivly on multicast instead of a simple LAN broadcast?

These two things are partially responsible for the failure of IPv6.
There is more political nonsense but on the technical side it is the thing
that makes IPv6 so stupidly complex.

--
:wq Claudio

Reply | Threaded
Open this post in threaded view
|

Re: Activating "ip6.forwarding" and "accept_rtadv" at the same time

Theo de Raadt
> I think the number 1 question I have about IPv6 is:
> What is wrong with arp?

Nothing is wrong with arp.

As a result of avoiding arp, IPv6 is a duck sitting in a tailing
pond.  It isn't dead yet.

Reply | Threaded
Open this post in threaded view
|

Re: Activating "ip6.forwarding" and "accept_rtadv" at the same time

Martin Pelikan
In reply to this post by Claudio Jeker
2010/9/7, Claudio Jeker <[hidden email]>:
> As soon as you spilt a /64 into something smaler you left IPv6 land end
> entered something that looks like IPv6 but isn't. Sure it is possible but
> by doing it you make every IPv6 disciple scream in agony (which is
> probably a good thing anyway).

I don't understand that agonizing part. I've heard of companies with
so stupid network policies (read: corporate environment) that DHCP6
with one /112 per department and sequentially assigned addresses
against people's MAC addresses is like a spit in the ocean. Most
people that would make it scream use some automated system for keeping
track of their machines anyway.

>> How would it look like? New ifconfig parameter?
> That was the plan.

And a new flag to struct in6_ifextra? Any particular ideas about the
loop prevention?

> What is wrong with arp?

Strange, I asked myself the same question :-) Theo is probably right.
Seems like they just wanted the whole concept separately. Were there
some political reasons for that?
Result? The code is written twice. Bad. But how does it bring down the
whole protocol?

> Why rely so massivly on multicast instead of a simple LAN broadcast?

Because not every machine in the network wants to speak IPv6? There
might be other local stuff (EtherSound is just a bad example)
demanding separate handling over the same L2 network and not to be
disturbed by anything else.
Multicasting ND traffic seems like a relief in huge L2 segments so
common to see these days instead of smaller routed subnets. But again,
the savings are like a spit in the ocean. I have yet to see network so
big that this is actually necessary performance-wise. People claim
there are...
But what's wrong with multicast these days?

> These two things are partially responsible for the failure of IPv6.

Failure? I don't know about America, but here in central Europe it
finally seems to be deploying well. And wait for China. (yes, I know
it's more like intranet, but they probably don't want to separate too
much)

> There is more political nonsense but on the technical side it is the thing
> that makes IPv6 so stupidly complex.

Again, I don't know about any political stuff (pointers?) but some of
the complexity surely is unnecessary. However it seems to be too late
to complain :-(

--
Martin Pelikan

Reply | Threaded
Open this post in threaded view
|

Re: Activating "ip6.forwarding" and "accept_rtadv" at the same time

Joakim Aronius
* Martin Pelikan ([hidden email]) wrote:

> 2010/9/7, Claudio Jeker <[hidden email]>:
> > As soon as you spilt a /64 into something smaler you left IPv6 land end
> > entered something that looks like IPv6 but isn't. Sure it is possible but
> > by doing it you make every IPv6 disciple scream in agony (which is
> > probably a good thing anyway).
>
> I don't understand that agonizing part. I've heard of companies with
> so stupid network policies (read: corporate environment) that DHCP6
> with one /112 per department and sequentially assigned addresses
> against people's MAC addresses is like a spit in the ocean. Most
> people that would make it scream use some automated system for keeping
> track of their machines anyway.

Why use smaller subnets than /64? Just keep it simple and go for /64s
everywhere, its even quite common to use /64s on point to point links.
The only reason is that net ops are used to IPv4 and try to conserve IP
addresses. In the end they will have an unnecessarily complicated network to
handle.

> > What is wrong with arp?

ND does a lot more than ARP. (..which, in itself, makes it more complex.)

> > These two things are partially responsible for the failure of IPv6.
>
> Failure? I don't know about America, but here in central Europe it
> finally seems to be deploying well. And wait for China. (yes, I know
> it's more like intranet, but they probably don't want to separate too
> much)

IPv6 is getting more and more attention, in the US too. So after a decade+ of
'IPv6 will happpen soon' it seems like things finaly start to happen.. and it
will surely be painfull :)

Cheers,
/Joakim

Reply | Threaded
Open this post in threaded view
|

Re: Activating "ip6.forwarding" and "accept_rtadv" at the same time

Claudio Jeker
In reply to this post by Martin Pelikan
On Thu, Sep 09, 2010 at 12:38:06PM +0200, Martin Pelikan wrote:

> 2010/9/7, Claudio Jeker <[hidden email]>:
> > As soon as you spilt a /64 into something smaler you left IPv6 land end
> > entered something that looks like IPv6 but isn't. Sure it is possible but
> > by doing it you make every IPv6 disciple scream in agony (which is
> > probably a good thing anyway).
>
> I don't understand that agonizing part. I've heard of companies with
> so stupid network policies (read: corporate environment) that DHCP6
> with one /112 per department and sequentially assigned addresses
> against people's MAC addresses is like a spit in the ocean. Most
> people that would make it scream use some automated system for keeping
> track of their machines anyway.
>

Real IPv6 Fanboys will tell you that anything smaller then /64 is a sin
and against the spirit of IPv6. You can not run all the great stuff that
makes IPv6 oh so superior. </sacrasm>

> >> How would it look like? New ifconfig parameter?
> > That was the plan.
>
> And a new flag to struct in6_ifextra? Any particular ideas about the
> loop prevention?
>

Nope, it will be part of ifnet->if_xflags.
You can not prevent loops. If users do stupid things they need to suffer
the consequences (that's how people learn). At least you should limit the
interfaces from where you accept rtadv packets.

> > What is wrong with arp?
>
> Strange, I asked myself the same question :-) Theo is probably right.
> Seems like they just wanted the whole concept separately. Were there
> some political reasons for that?
> Result? The code is written twice. Bad. But how does it bring down the
> whole protocol?

Because ND depends on multicast and therefor needs a local scope and
because of this we end up with addressing scopes and then we need
stateless address assignment on the local scope with duplicate address
detection and now you're deep down in the darkest of the dark holes.

> > Why rely so massivly on multicast instead of a simple LAN broadcast?
>
> Because not every machine in the network wants to speak IPv6? There
> might be other local stuff (EtherSound is just a bad example)
> demanding separate handling over the same L2 network and not to be
> disturbed by anything else.
> Multicasting ND traffic seems like a relief in huge L2 segments so
> common to see these days instead of smaller routed subnets. But again,
> the savings are like a spit in the ocean. I have yet to see network so
> big that this is actually necessary performance-wise. People claim
> there are...
> But what's wrong with multicast these days?
>

Hmm. Please show me a switch that actually does the ND multicast in a
non-flooding way. By default most multicast is treated like broadcast and
is flooded all over the place. So there is no gain for a hell lot of pain.
There is nothing wrong with mutlicast where multicast is needed but
neighbor discovery (aka address resolution) is not one of those cases.
Sure the theory sounds sexy but in reality it is just painful.

> > These two things are partially responsible for the failure of IPv6.
>
> Failure? I don't know about America, but here in central Europe it
> finally seems to be deploying well. And wait for China. (yes, I know
> it's more like intranet, but they probably don't want to separate too
> much)
 
It is a forced deployment and it is only possible because many things
implied with IPv6 got killed. It is funny that all those things that
should never ever be needed in IPv6 are suddenly implemented (best example
dhcp6).

> > There is more political nonsense but on the technical side it is the thing
> > that makes IPv6 so stupidly complex.
>
> Again, I don't know about any political stuff (pointers?) but some of
> the complexity surely is unnecessary. However it seems to be too late
> to complain :-(
 
As an example of political nonsense look at what it took to be able to get
PI IPv6 space.

--
:wq Claudio

Reply | Threaded
Open this post in threaded view
|

Re: Activating "ip6.forwarding" and "accept_rtadv" at the same time

Martin Pelikan
2010/9/9, Claudio Jeker <[hidden email]>:
>> And a new flag to struct in6_ifextra?
>
> Nope, it will be part of ifnet->if_xflags.

Actually, it's already in in6_ifextra->nd_ifinfo->flags, named
ND6_IFF_ACCEPT_RTADV and controlled by the "ndp -i" command. However,
ifconfig autoconfprivacy uses if_xflags and separating these two looks
kind of dirty... Wouldn't it be better to move autoconfprivacy from
ifconfig to ndp (as privacy_rtadv flag)? The option name is pretty
long and the thing is ndp-related... How much would have people
suffered from that change?

And slowly back to the original question. Is it safe to allow
accepting RAs on a router then? I mean in terms of messing with
default router list (make sure the routines only touch RTF_CONNECTED
and correct those XXX'ed conditions with ip forwarding). BTW: RTF_MAX
comment should be "minimum priority" instead of "maximum" :-)

> Because ND depends on multicast and therefor needs a local scope and
> because of this we end up with addressing scopes and then we need
> stateless address assignment on the local scope with duplicate address
> detection and now you're deep down in the darkest of the dark holes.

Strange, I always thought that stateless address assignment and
link-local scope were the features of the protocol :-) DAD just comes
up because it's obviously necessary. And maybe they thought multicast
queries were a bonus for ISPs which cheap switches would broadcast
anyway.

> Hmm. Please show me a switch that actually does the ND multicast in a
> non-flooding way. By default most multicast is treated like broadcast and
> is flooded all over the place. So there is no gain for a hell lot of pain.

Our peer's Cizcoe C4900M for example. I'm going to test our 3com 4200G
as it should work too. I guess in the size that you really need it,
you already have the money to find a switch that supports it. (and
they probably hoped the manufacturers would cooperate ;-))

> There is nothing wrong with mutlicast where multicast is needed but
> neighbor discovery (aka address resolution) is not one of those cases.
> Sure the theory sounds sexy but in reality it is just painful.

You got that right, it isn't necessary here. I guess I'm just lucky
not being painfully hurt.

> It is a forced deployment and it is only possible because many things
> implied with IPv6 got killed. It is funny that all those things that
> should never ever be needed in IPv6 are suddenly implemented (best example
> dhcp6).

I thought that that's why the autonomous flag in RA was for from the
very beginning. The RFC from august 1996 has a reference to DHCPv6 in
it...
But yes, a lot of simple things should've been there from the
beginning (RFC 5006 being probably the most user-visible one)

> As an example of political nonsense look at what it took to be able to get
> PI IPv6 space.

Okay, I get it now...

--
Martin Pelikan