[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DSTM

On 24-jun-04, at 5:37, Margaret Wasserman wrote:

I am less certain that there is a real need for DSTM today.

Good! So we have the chance to be proactive.

I have not personally heard any ISP or Enterprise operators indicate their intention to run IPv6-only backbones any time soon.

Probably because the notion that this could be a viable option hasn't entered the brains of the decision makers yet.

If you consider the complexities of building a large IPv4 network, especially if you want to avoid NAT but don't have a lot of address space, versus the simplicity of building a similar network using IPv6, it makes sense that people will want to run an IPv6-only network and tunnel IPv4 over it where needed as soon as the necessary mechanisms (IPv4-in-IPv6 tunneling, IPv6 DNS resolver discovery) are available and all the hardware can handle IPv6 in the fast path. (I had a few conversations with vendors at the summit thing last week and many still do IPv6 in software.)

I'm also not sure how/why we need a specific DSTM server at all... How is DSTM superior to using a DHCPv6 option to get the configuration information needed to set-up a configured IPv4-in-IPv6 tunnel and then using DHCPv4 over that tunnel?

I for one am not in favor of making DHCPv6 a dependency.

I also have another problem with DSTM as it is: it depends on a single gateway. That's not good. We need redundancy.

It might be better to create an IPv4-in-IPv6 tunneling mechanism that treats the IPv6 network as an IPv4 link layer and run standard IPv4 protocols such as ARP and DHCP over that. (Similar to 6over4 but the other way around.) This should work very well in networks that support site-wide multicast. (There are some security issues with rogue DHCPv4 servers but those can be mitigated by filtering broad/multicasts.)

However, we may also want to consider the situation where a user is roaming on a standard issue IPv6 network far away, and wants to tunnel back home. There are already various VPN solutions that do this for IPv4 over IPv4, though, so hopefully we don't have to reinvent the wheel here.

One remark about the draft: there are some serious line length issues, please fix as this makes some parts very hard to read.