To help me sort through the mail on this list, please include the following tags in the subject. I believe 99% of the mail can be categorized in the first 3
1. [ipv6 high fives] IPv6 people patting themselves on the back, "i told you so" ... 2. [ipv6 religion] discussion of ULA being evil, subnet sizes, NAT is bad, explaining to people how there is only one way to run an IPv6 network... 3. [advertisements] services you are offering, including training classes you are providing 4. [Something useful] this is the one i plan to read
All joking aside, i don't think this list has lived up to its name yet. I will give it a little while longer before sending a mail to the list asking how to unsubscribe (ha!)
> All joking aside, i don't think this list has lived up to its name > yet. I will give it a little while longer before sending a mail to > the list asking how to unsubscribe (ha!)
+1
On perhaps a more constructive note, I'd be interested in a discussion on where things could go wrong with IPv6 implementations. And by that, I mean networking stacks and firewalls. Where are the RFCs vague/confusing? What policy details are likely to be overlooked by JoeSecurity's v6 firewall product?
(If anyone has an android device that is IPv6 capable and wants to send me DNS and port 80 tcpdump traces of the device attempting to connect to the URLs listed at the end of the article I'd be grateful)
> To help me sort through the mail on this list, please include the > following tags in the subject. I believe 99% of the mail can be > categorized in the first 3
> 1. [ipv6 high fives] IPv6 people patting themselves on the back, "i > told you so" ... > 2. [ipv6 religion] discussion of ULA being evil, subnet sizes, NAT is > bad, explaining to people how there is only one way to run an IPv6 > network... > 3. [advertisements] services you are offering, including training > classes you are providing > 4. [Something useful] this is the one i plan to read
> All joking aside, i don't think this list has lived up to its name > yet. I will give it a little while longer before sending a mail to > the list asking how to unsubscribe (ha!)
>> All joking aside, i don't think this list has lived up to its name >> yet. I will give it a little while longer before sending a mail to >> the list asking how to unsubscribe (ha!)
> +1
> On perhaps a more constructive note, I'd be interested in a discussion > on where things could go wrong with IPv6 implementations. And by > that, I mean networking stacks and firewalls. Where are the RFCs > vague/confusing? What policy details are likely to be overlooked by > JoeSecurity's v6 firewall product?
Someone mailed me this today...
> My current barrier to v6 is knowing what I'm meant to do to have more than one provider with v6 without BGP and a range allocation.
> With v4 it's simple. The internal network is private and the router just flips NAT to the other providers IP/32.
> With BGP and a range allocation I can see that's not an issue, you just announce your existence.
> But is the idea that all small businesses who just want to have two providers for reliability reasons, are going to have to have an allocation and be running BGP?
Frankly my answer was not very complimentary about the current set of IPv6 specs and RFCs. If you are looking for gaping holes in the IPv6 story then this is unfortunately one of them.
On Wed, Nov 30, 2011 at 10:57 PM, Geoff Huston <g...@apnic.net> wrote:
> On 01/12/2011, at 1:31 PM, Tim wrote:
>>> All joking aside, i don't think this list has lived up to its name >>> yet. I will give it a little while longer before sending a mail to >>> the list asking how to unsubscribe (ha!)
>> +1
>> On perhaps a more constructive note, I'd be interested in a discussion >> on where things could go wrong with IPv6 implementations. And by >> that, I mean networking stacks and firewalls. Where are the RFCs >> vague/confusing? What policy details are likely to be overlooked by >> JoeSecurity's v6 firewall product?
> Someone mailed me this today...
>> My current barrier to v6 is knowing what I'm meant to do to have more than one provider with v6 without BGP and a range allocation.
>> With v4 it's simple. The internal network is private and the router just flips NAT to the other providers IP/32.
>> With BGP and a range allocation I can see that's not an issue, you just announce your existence.
>> But is the idea that all small businesses who just want to have two providers for reliability reasons, are going to have to have an allocation and be running BGP?
> Frankly my answer was not very complimentary about the current set of IPv6 specs and RFCs. If you are looking for gaping holes in the IPv6 story then this is unfortunately one of them.
i.e. DHCPv6 based assignments may need NPTv6 RFC6296.
A likely case for a NAT would be NAT64 defined in RFC6144, RFC6145, RFC6146, RFC6052, RFC6147, and RFC6384. Multihoming has been a long standing feature of SCTP prominently used in cellular and multimedia communications where reliability and performance is essential.
There is also an interesting informational rfc regarding IPv6-only networks and the use of NAT64. This points to incidents involving IPv4 literals that require work-around approaches in less than %2 of the cases within IPv6 only networks.
Section 3.2 DNS Operation ,--- Router Advertisements are used to carry DNS Configuration options [RFC6106 <http://tools.ietf.org/html/rfc6106>], listing the DNS64 as the DNS server the hosts should use. In addition, aliases were added to the DNS64 device to allow it to receive packets on the well-known DNS server addresses that Windows operating systems use (fec0:0:0:ffff::1, fec0:0:0:ffff::2, and fec0:0:0:ffff::3). At a later stage support for stateless DHCPv6 [RFC3736 <http://tools.ietf.org/html/rfc3736>] was added. We do recommend enabling RFC6106, well-known addresses, and stateless DHCPv6 in order to maximize the likelihood of different types of IPv6-only hosts being able to use DNS without manual configuration. DNS server discovery was never a problem in dual-stack networks, because DNS servers on the IPv4 side can easily provide IPv6 information (AAAA records) as well. With IPv6-only networking, it becomes crucial that the local DNS server can be reached via IPv6 as well. '---
Other notes: Mac OS X the network manager needed to be explicitly told to not expect IPv4. Windows 7 experienced problems when relying on default, well-known DNS server addresses: without manual configuration, the host was unable to use the DNS addresses, even though the system displays them as current DNS server addresses.
