[ipv6hackers] subject labels

[Cameron Byrne]

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!)

cb
_______________________________________________
Ipv6hackers mailing list
Ipv6h...@lists.si6networks.com
http://lists.si6networks.com/listinfo/ipv6hackers

[Tim]

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

tim

[Geoff Huston]

So I did some hacking that might get over Cameron's threshold.

Not to build anything, but to look at the dual stack world.

I set up a packet tracer, a bunch of OSes on VMs with a set of browsers, a dual stack service and a set of URLs that are broken in various ways.

And the results are here...http://www.potaroo.net/ispcol/2011-12/esotropia.html

(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)

cheers,

Geoff

[Geoff Huston]

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.

Geoff

[Richard Barnes]

Well, there are some people thinking about the problem
<http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03>

There's even an RFC
<http://tools.ietf.org/html/rfc6296>

[Douglas Otis]

On 11/30/11 8:22 PM, Richard Barnes wrote:
> Well, there are some people thinking about the problem
>
<http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03>
>
> There's even an RFC
> <http://tools.ietf.org/html/rfc6296>

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.

http://tools.ietf.org/html/draft-garcia-shim6-applicability-02

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.

http://tools.ietf.org/html/draft-arkko-ipv6-only-experience-04

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.

-Doug

[Jim Small]

I just wanted to say that this is a fantastic read:
http://tools.ietf.org/html/draft-arkko-ipv6-only-experience-04

Highly recommended if you haven't perused it already and thanks for pointing it out Doug,
--Jim