Probably a case of something being blindingly obvious but...
I have seen plenty of information on IPv6 from a internal network standpoint. I have seen very little with respect to how a ISP is supposed to handle routing to residential consumer networks. I have seen suggestions of running RIPng. The thought of letting Belkin routers (if you can call them that) into the routing table scares me no end.
Is this way easier than I think it is? Did somebody already write the book that I can't find?
Probably a case of something being blindingly obvious but...
I have seen plenty of information on IPv6 from a internal network
standpoint. I have seen very little with respect to how a ISP is
supposed to handle routing to residential consumer networks. I have seen
suggestions of running RIPng. The thought of letting Belkin routers (if
you can call them that) into the routing table scares me no end.
Here here! This cheap consumer junk is KILLING the internet, you can't trust any of this garbage for 5 damn seconds, let alone actually configure any moderately advanced setup and expect them to keep operating for any length of time.
Is this way easier than I think it is? Did somebody already write the
book that I can't find?
I'd love to see it too. We're a small ISP and just keeping the business going is hard enough without having to learn the entire v6 protocol suite, we need more help otherwise we're likely to just keep putting it off.
Mike
DHCPv6-PD (prefix delegation) with the relay installing static routes
is probably the most straightforward way. Letting home CPE participate
in routing does indeed seem like bad idea; I haven't heard that
seriously suggested before.
-Ben
I had found the documentation on DHCPv6-PD but didn't see the mechanism for getting the assigned prefixes into the router.
Mark
RADIUS.
When your session comes up you get, in our trial (http://ipv6.internode.on.net) a /64 assigned to your PPP interface.
You can choose to send an RA and assigned your router an IP in this or not.
Otherwise your router sends a DHCPv6 PD request to our BRAS. Our BRAS knows who you are and does a radius request. Our RADIUS server sends back either a pool name or a static /60 (for the trial) which then gets routed to your interface. You then assign internally as required.
MMC
Probably a case of something being blindingly obvious but...
I have seen plenty of information on IPv6 from a internal network
standpoint. I have seen very little with respect to how a ISP is
supposed to handle routing to residential consumer networks. I have seen
suggestions of running RIPng. The thought of letting Belkin routers (if
you can call them that) into the routing table scares me no end.Is this way easier than I think it is? Did somebody already write the
book that I can't find?
"Deploying IPv6"
Probably a case of something being blindingly obvious but...
I have seen plenty of information on IPv6 from a internal network
standpoint. I have seen very little with respect to how a ISP is
supposed to handle routing to residential consumer networks. I have seen
suggestions of running RIPng. The thought of letting Belkin routers (if
you can call them that) into the routing table scares me no end.Is this way easier than I think it is? Did somebody already write the
book that I can't find?
Make that
"Deploying IPv6 Networks"
DHCPv6-PD (prefix delegation) with the relay installing static routes
is probably the most straightforward way.
Apparently that has it's own problems right now actually:
Letting home CPE participate
in routing does indeed seem like bad idea; I haven't heard that
seriously suggested before.
I guess "Comcast Business Class" cable service isn't necessarily
considered home service, but I wouldn't call it a dedicated bandwidth
contract either. The CPE that they use (SMCD3G or similar) actually
does this for v4, that is if you purchase a "Static IP Block" from
them, they actually use RIPv2 to send your prefix (usually a /27 or
longer) to the headend. Obviously authentication is used and the CPE
firmware prevents the end user from tampering with any part of the RIP
configuration, but the point is that RIP actually is used at a large
scale for this purpose.
-Bill
In article <xs4all.AANLkTin5aOQKLbiXfN9ELNpoDLBCDxn1E0ATi7wbU_XA@mail.gmail.com> you write:
DHCPv6-PD (prefix delegation) with the relay installing static routes
is probably the most straightforward way.Apparently that has it's own problems right now actually:
DHCPv6 relaying: another trouble spot? « ipSpace.net blog
Well, the problem described there is exactly the same problem that
already exists with plain IPv4 DHCP (a pity that FORCERENEW (rfc3203)
or something like it never took off).
If you use PPPoA/PPPoE/PPPoX with DHCPv6 PD, the problem described there
doesn't exist if your CPE is at least halfway intelligent .. it should
ofcourse do a new lease request (at least a renewal) after a PPP reconnect.
Mike.
of running RIPng. The thought of letting Belkin routers (if you can call
them that) into the routing table scares me no end.
I think that indeed looks scary. I wouldn't be too concerned about the
Belkin routers.
How many SP routers are really designed to deal with mass numbers of
RIP adjacencies?
RIPng sounds like a plan to deploy 2 or 3 IPv6 end networks, not really better
than static manual configuration, and with significant disadvantages.
So I would suggest static manual configuration of the port on
routers facing the
CPE, no RIPng. If there are routes to be exchanged with a downstream user,
use a proper EGP as one would the IPv4.
Use a CPE of a type that scripts can be written to configure, for
large scale deployments.
If there is an inexpensive CPE with an implementation of DHCPv6 PD
that works without issues,
I would love to hear about who makes it, and what the device is...
In our deployment mode, the CEs are running PPP sessions to the
BRAS, so they know when it reboots and can respond accordingly.
Layer 3 access networks could conceivably have an issue here, though.
It's almost as if everyone ought to have been working on this a decade
ago so that we'd have a workable solution by now! 
- mark
In article <xs4all.AANLkTikm-=0xT8kJV0_0GbC7FZXofOBn+Fh8oiL6VjuQ@mail.gmail.com> you write:
If there is an inexpensive CPE with an implementation of DHCPv6 PD
that works without issues,
I would love to hear about who makes it, and what the device is...
AVM Fritzbox 7270/7340/7390
Draytek Vigor 2130/2750
Those are the ones I tested, there are lots more, but according to
"To date, there is not one complete implementation of IPv6 on a
residential consumer-grade xDSL modem available in North America."
Mike (using native IPv6 over PPPoA + DHCPv6 PD over ADSL).
RIP doesn't have adjacencies, per se. It's basically a stateless broadcast
based protocol. As such, the number of routers really has no major impact
other than the traffic level generated by all those broadcasts.
Owen
Another list of pointers can be found at http://labs.ripe.net/Members/mirjam/ipv6-cpe-surveys/.
Feedback on how these boxes do in a real environment are welcome as thers is still a lot of beta, unfinished implementations, bugs and vapourware around these days.
Marco
---end quoted text---
I found the following very helpful, Hardest thing for me was nailing
DHCPv6-PD without an DHCP server
Deploying IPv6 in Broadband Access Networks
By: Adeel Ahmed; Salman Asadullah
Publisher: John Wiley & Sons
Pub. Date: August 17, 2009
Print ISBN: 978-0-470-19338-9
Web ISBN: 0-470193-38-7
Deploying IPv6 Networks
By: Ciprian Popoviciu; Eric Levy-Abegnoli; Patrick Grossetete
Publisher: Cisco Press
Pub. Date: February 10, 2006
Print ISBN-10: 1-58705-210-5
Print ISBN-13: 978-1-58705-210-1
This is the best/most complete work on IPv6 security to date, IMHO:
<http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945>
Speaking of IPV6 security, is there any movement towards any open source
IPV6 firewall solutions for the consumer / small business?
Almost all the info I've managed to find to date indicates no support, nor
any planned support in upcoming releases.
Any info would be helpful.
cheers
Jeff
Honestly (and I'm sure some IPv6 folks will want me injured as a result) there should be some '1918-like' space allocated for the corporate guys who "don't get it", so they can nat everyone through a single /128. It would make life easier for them and quite possibly be a large item in pushing ipv6 deployment in the enterprise.
I don't see our corporate IT guys that number stuff in 1918 space wanting to put hosts on 'real' ips. The chances for unintended routing are enough to make them say that v6 is actually a security risk vs security enabler is my suspicion.
- Jared
Speaking of IPV6 security, is there any movement towards any open source
IPV6 firewall solutions for the consumer / small business?Almost all the info I've managed to find to date indicates no support, nor
any planned support in upcoming releases.Any info would be helpful.
Honestly (and I'm sure some IPv6 folks will want me injured as a result) there should be some '1918-like' space allocated for the corporate guys who "don't get it", so they can nat everyone through a single /128. It would make life easier for them and quite possibly be a large item in pushing ipv6 deployment in the enterprise.
Yes... Those of us who would like to see sanity return to the internet would prefer to have you lynched for such heresy. 
Seriously, though, you're welcome to use fd00::/8 for exactly that purpose. The problem is that you (and hopefully it stays this way)
won't have much luck finding a vendor that will provide the NAT for you to do it with.
I don't see our corporate IT guys that number stuff in 1918 space wanting to put hosts on 'real' ips. The chances for unintended routing are enough to make them say that v6 is actually a security risk vs security enabler is my suspicion.
There are multiple easy ways to solve this problem that don't require the use of NAT or the damage that comes with it.
First, let's clarify things a bit. I don't think unintended routing is what concerns your IT guys. Afterall, even with the NAT
box today, there's routing from the outside to the inside. It's just controlled by stateful inspection.
It's trivial to implement an IPv6 default-deny-inbound stateful inspection policy that provides exactly the same security
model as is afforded by the current NAT box in IPv4 without mangling the packet headers. The rest is superstition.
Admittedly, superstition is powerful among IT professionals, especially in the enterprise world. So strong that people
on this very list who I generally respect and consider to be good competent professionals tell me that I'm flat out
wrong about it.
However, not one of them has been able to produce an argument that actually stands up to scrutiny. The closest they
can come is what happens when someone misconfigures something. However, I've always been able to show that
it's equally easy to make fatal misconfigurations on the NAT box with just as dire consequences.
Owen
Seriously, though, you're welcome to use fd00::/8 for exactly that
purpose. The problem is that you (and hopefully it stays this way)
won't have much luck finding a vendor that will provide the NAT for
you to do it with.
Corporate IT community *expects* a broken Internet. They aren't doing their jobs if they haven't broken everything and it's dog. Vendors will provide what their customers demand, so there will be NAT on the corporate firewalls.
What I don't want to see is NAT on home routers.
There are multiple easy ways to solve this problem that don't require
the use of NAT or the damage that comes with it.
Corporations thrive on damaging traffic, and many prefer NAT. Every instinct in their body screams that removing NAT is bad, and you won't win that argument.
First, let's clarify things a bit. I don't think unintended routing
is what concerns your IT guys. Afterall, even with the NAT box today,
there's routing from the outside to the inside. It's just controlled
by stateful inspection.
1918 space generally isn't routed to their firewall from the outside, so some mistakes that leave the inside vulnerable are actually somewhat protected by using 1918 space which isn't routed. It's a limited scenario, but what every corp IT guy I know points to.
So strong that people on this very list who I generally respect and
consider to be good competent professionals tell me that I'm flat
out wrong about it.
It's not superstition that the IP addresses assigned to the inside aren't routed from the upstream to to outside interface of the firewall. ie, when NAT/SPI is broken, the traffic itself breaks, not a sudden "We are wide open!" event.
This is not about *proper* security. It is about the extra gain when someone screws up and kills the firewall ruleset. In a 1 to 1 NAT environment, losing your SPI would be bad. In a 1 to N NAT environment, a majority of the machines can never be reached if the SPI/NAT engine dies (unless the upstream suddenly adds a 1918 route to reach them).
However, not one of them has been able to produce an argument that
actually stands up to scrutiny. The closest they can come is what
happens when someone misconfigures something. However, I've always
been able to show that it's equally easy to make fatal
misconfigurations on the NAT box with just as dire consequences.
It is possible, yes. However, in the case of an overloaded NAT without port forwarding, there is no way to reach the backend hosts unless the upstream adds a route to the 1918 space behind the firewall. This is what people object to. A single route. That's it. If NAT doesn't work, the route is required. Without NAT, if your SPI doesn't work, the route is already there and you may have defaulted open.
So does NAT add to security? Yes; just not very much. It covers one condition; that is all. For that condition, you have a huge amount of service breakage. For a corporate network, this may be perfectly fine and acceptable.
Jack