IPV6 renumbering painless?

Kevin_Oberman · November 11, 2004, 4:44pm

From: Michael.Dillon@radianz.com
Date: Thu, 11 Nov 2004 16:22:28 +0000
Sender: owner-nanog@merit.edu

> I guess you also want to announce a /64 into the IPv6 BGP tables ?

Correct me if I'm wrong, but doesn't IPv6 do away
with the need to renumber when switching providers?
So if RFC 2462 is right, and you use DNS outside
your network and you update that DNS at the moment
of switching providers, everything on your network
automatically acquires new IPv6 globally routable
addresses as soon as the gateway router is connected
to the new provider. Seems to me that with a little
bit of help from a "Change providers" tool, this
would be virtually painless without the need to
own or announce a small globally unique prefix.

We have renumbered IPv6 space a couple of times when we were developing
our addressing plan. (We have a /32.) Renumbering was pretty trivial for
most systems, but servers requiring a fixed address were usually
configured with an explicit prefix. This should not have been the case,
but most people configured IPv6 addresses pretty much like IPv4 and
specified the entire 128 bits. Of course, after a renumbering, this gets
fixed, so those systems are usually OK the next time.

DNS is an issue, but still pretty easy IF you set things properly. This
is more likely than having servers set up right as the right way is
usually what most people would tend to do without thinking about it.

On the whole, it's pretty fast and easy, but there are always a few
bumps in the road.

Daniel_Roesen · November 11, 2004, 5:46pm

"specified the entire 128 bits"... how do you specify only part of
it? What determines the rest?

"fixed" as in "now using stateless autoconfig"? Fun... change NIC and
you need to change DNS. Thanks, but no thanks. Not for non-mobile
devices which need to be reachable with sessions initiated from remote
(basically: servers).

Best regards,
Daniel

Tony_Hain · November 11, 2004, 8:05pm

Daniel Roesen wrote:

...

"fixed" as in "now using stateless autoconfig"? Fun... change NIC and
you need to change DNS. Thanks, but no thanks. Not for non-mobile
devices which need to be reachable with sessions initiated from remote
(basically: servers).

You are allowed to do either / both, or DHCP. If you are talking about a
server you want a static value, while it may not make sense to explicitly
manage every client. If you don't want to statically configure devices there
is always DHCPv6. The point is you can do what you do today, then there are
new capabilities for autoconfiguration that can be used when it makes sense
to lower operational costs.

Tony

Daniel_Roesen · November 12, 2004, 12:44am

Well, but all you said is in no way different to the IPv4 world and
thus doesn't make renumbering any more easier than in IPv4.

And yes, I think all the workstations WILL need to do DHCP and not
use stateless autoconfig. Workstations are being managed by IT
departments, and they do want to be able to SSH to them all and have
DNS forward/reverse mapping.

I can see NOTHING in IPv6 which makes real world networks any easier
to renumber than IPv4 networks ASIDE the fact that if /48 addressing
is used, renumbering becomes a search-and-replace thing for large
parts of it.

Stateless autoconfig doesn't really provide any added value for ad-hoc
mobile clients than DHCP does in v4 - au contraire, as all the other
information a DHCP server might offer is not provided with stateless
autoconfig.

Stateless autoconfig DOES have uses, but those are for most of us
just exotic corner cases, IMHO.

Regards,
Daniel (who will soon renumber his private network /48 a third time
since he has IPv6 connectivity)

Simon_Leinen1 · November 12, 2004, 4:19pm

Daniel Roesen writes:

We have renumbered IPv6 space a couple of times when we were
developing our addressing plan. (We have a /32.) Renumbering was
pretty trivial for most systems, but servers requiring a fixed
address were usually configured with an explicit prefix. This
should not have been the case, but most people configured IPv6
addresses pretty much like IPv4 and specified the entire 128
bits. Of course, after a renumbering, this gets fixed, so those
systems are usually OK the next time.

"specified the entire 128 bits"... how do you specify only part of
it?

On Solaris, you would use the "token" option (see the extract from
"man ifconfig" output below). You can simply put "token :5678"
into /etc/hostname6.bge0. I assume that other sane OSes have similar
mechanisms.

602 token address/prefix_length
603 Set the IPv6 token of an interface to be used for
604 address autoconfiguration.
605
606 example% ifconfig hme0 inet6 token ::1/64
607

What determines the rest?

The prefix advertised in prefix advertisements.

"fixed" as in "now using stateless autoconfig"? Fun... change NIC
and you need to change DNS. Thanks, but no thanks. Not for
non-mobile devices which need to be reachable with sessions
initiated from remote (basically: servers).

The above mechanism solves this problem even with stateless
autoconfiguration. Agree?

I think it's an advantage if servers can get their prefixes from
router announcements rather than from local config files. Sure, you
still have to update the DNS at some point(s) during renumbering, but
that can't be avoided anyway.

Nils_Ketelsen · November 12, 2004, 6:43pm

And yes, I think all the workstations WILL need to do DHCP and not
use stateless autoconfig. Workstations are being managed by IT
departments, and they do want to be able to SSH to them all and have
DNS forward/reverse mapping.

Ohh, Autoconfig (with the MAC-Address in the host bits) actually makes
it easier for me to log into a workstation.

I just keep 2 lists:

1) all prefixes in my network
2) all Macaddresses in use.

Now I can loop through all prefixes and try to ping the macaddress I want
to reach (with the occasional fffe in the middle).

Hoping that the MAC is really unique (we do not use 3com cards
anymore) I can actually find a specific Laptop on my network
easy without even knowing where the user is.

I can see NOTHING in IPv6 which makes real world networks any easier
to renumber than IPv4 networks ASIDE the fact that if /48 addressing
is used, renumbering becomes a search-and-replace thing for large
parts of it.

I agree to that, though.

Stateless autoconfig doesn't really provide any added value for ad-hoc
mobile clients than DHCP does in v4 - au contraire, as all the other
information a DHCP server might offer is not provided with stateless
autoconfig.

Knowing what the host-part of the IP-Address will be for the a
specific device is an advantage I believe.

Nils

Daniel_Roesen · November 12, 2004, 9:26pm

> "specified the entire 128 bits"... how do you specify only part of
> it?

On Solaris, you would use the "token" option (see the extract from
"man ifconfig" output below). You can simply put "token :5678"
into /etc/hostname6.bge0. I assume that other sane OSes have similar
mechanisms.

Ah thanks. No, not seen anywhere in Linux or *BSD.

> What determines the rest?

The prefix advertised in prefix advertisements.

OK, but this doesn't have any effect on your "Listen",
"NameVirtualHost" and "<VirtualHost>" statements of your httpd.conf,
"ListenAddress" in sshd.conf, "Bind" in proftpd.conf, "*-source" and
"listen-on*" in named.conf, [...]

Not to forget all the IP address based ACLs.

> "fixed" as in "now using stateless autoconfig"? Fun... change NIC
> and you need to change DNS. Thanks, but no thanks. Not for
> non-mobile devices which need to be reachable with sessions
> initiated from remote (basically: servers).

The above mechanism solves this problem even with stateless
autoconfiguration. Agree?

The NIC-change problem? Yes, agreed. But generates new problem: Plug
server accidently in wrong VLAN (and thus other subnet) and you'll
might get an IP address collision. I know ND DAD prevents the worst
for that case in the immediate term, but when the original holder
gets reconnected/rebootet, THIS one is off their air. But you're right,
typos in IPv4 might provoke similar desasters so I rest this specific
case.

I think it's an advantage if servers can get their prefixes from
router announcements rather than from local config files. Sure, you
still have to update the DNS at some point(s) during renumbering, but
that can't be avoided anyway.

Given that a server often has to know it's exact IP address very
often (especially if it has multiple IP addresses associated with
it's public interface), it's not a real relief compared to the other
struggles you have when subnet changes.

Regards,
Daniel

Simon_Leinen1 · November 12, 2004, 9:52pm

Daniel Roesen writes:

Crist_Clark1 · November 12, 2004, 10:08pm

Daniel Roesen wrote:

"specified the entire 128 bits"... how do you specify only part of
it?

On Solaris, you would use the "token" option (see the extract from
"man ifconfig" output below). You can simply put "token :5678"
into /etc/hostname6.bge0. I assume that other sane OSes have similar
mechanisms.

Ah thanks. No, not seen anywhere in Linux or *BSD.

I would expect it to be an configuration option for rtsold(8) in KAME-
derived stacks and not in ifconfig(8). Errr... Not that I see it in there
either.

Trying to check a more recent KAME code base brings me to a real question
I've had. Does http://www.kame.net/ have an IPv4 mirror somewhere?

$ dig @orange.kame.net www.kame.net any

   ; <<>> DiG 8.3 <<>> @orange.kame.net www.kame.net any
   ; (2 servers found)
   ;; res options: init recurs defnam dnsrch
   ;; got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54483
   ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
   ;; QUERY SECTION:
   ;; www.kame.net, type = ANY, class = IN

;; ANSWER SECTION:
www.kame.net. 1D IN AAAA 2001:200:0:8002:203:47ff:fea5:3085

   ;; AUTHORITY SECTION:
   kame.net. 1D IN NS orange.kame.net.
   kame.net. 1D IN NS ns1.itojun.org.

   ;; ADDITIONAL SECTION:
   orange.kame.net. 1D IN A 203.178.141.194
   orange.kame.net. 1D IN AAAA 2001:200:0:8002:203:47ff:fea5:3085

   ;; Total query time: 160 msec
   ;; FROM: sec-tools.corp.globalstar.com to SERVER: 203.178.141.194
   ;; WHEN: Fri Nov 12 14:05:13 2004
   ;; MSG SIZE sent: 30 rcvd: 151

Christopher_L_Morro1 · November 12, 2004, 10:23pm

Daniel Roesen writes:
>> We have renumbered IPv6 space a couple of times when we were
>> developing our addressing plan. (We have a /32.) Renumbering was
>> pretty trivial for most systems, but servers requiring a fixed
>> address were usually configured with an explicit prefix. This
>> should not have been the case, but most people configured IPv6
>> addresses pretty much like IPv4 and specified the entire 128
>> bits. Of course, after a renumbering, this gets fixed, so those
>> systems are usually OK the next time.

> "specified the entire 128 bits"... how do you specify only part of
> it?

On Solaris, you would use the "token" option (see the extract from
"man ifconfig" output below). You can simply put "token :5678"

one presumes solaris <> 7 or 8 then, which solaris would this be in?

: man ifconfig | grep token

Reformatting page. Please Wait... done

I'd note that a simple:
echo "up" >> /etc/hostname6.hme0

will get you 'autoconfigured' v6 on solaris 8 though, and add to
/etc/inet/ipnodes:
<node address> <node name>

and fix /etc/nsswitch.conf:
ipnodes: files dns

after that, ping/traceroute/telnet/ftp all work correctly with ipv6. I was
cursing sun/solaris until I figured that part out

I think it's an advantage if servers can get their prefixes from
router announcements rather than from local config files. Sure, you
still have to update the DNS at some point(s) during renumbering, but
that can't be avoided anyway.

and change that all when the interface on the server fries out and a
replacement is put into the box, with a new 'autoconfigured' ip address...
or if your 'service' is a virtual ip on a server... things get
complicated, it's 'fun' Autoconfig has it's place, which is far from
'everywhere'.

-chris
ipv6-n00b

Paul_A_Vixie4 · November 12, 2004, 11:12pm

> > "specified the entire 128 bits"... how do you specify only part of it?
>
> On Solaris, you would use the "token" option ...

Ah thanks. No, not seen anywhere in Linux or *BSD.

we (ISC) asked KAME about this, and they suggested:

% cat /etc/start_if.nge0
ifconfig nge0 inet6 fe80::1

...which for freebsd 5.2.1 at least, has the right effect. rtsol still runs,
and once the upper 64 bits are known, the obvious thing happens:

        % ifconfig nge0 | grep ::
        inet6 fe80::1%nge0 prefixlen 64 scopeid 0x5
        inet6 2001:4f8:3:bb::1 prefixlen 64 autoconf

...so it's not as easy as the solaris "token" thing described earlier in this
thread, but it actually works fine and it's become universal on ISC's hosts.

Owen_DeLong · November 13, 2004, 1:06am

OK, but this doesn't have any effect on your "Listen",
"NameVirtualHost" and "<VirtualHost>" statements of your httpd.conf,
"ListenAddress" in sshd.conf, "Bind" in proftpd.conf, "*-source" and
"listen-on*" in named.conf, [...]

True. However, in all of the cases above except named.conf,
names are a perfectly valid substitute for the IP address.

Not to forget all the IP address based ACLs.

I suspect that eventually, we will discover that ADDRESS-based
ACLs simply do not scale to a V6 world, and, you will see support
for other strategies, such as host-name based ACLs.

Given that a server often has to know it's exact IP address very
often (especially if it has multiple IP addresses associated with
it's public interface), it's not a real relief compared to the other
struggles you have when subnet changes.

In most of those instances, the server can get it's address from
a nameservice, and, only really needs to know the unique name
for the correct address.

Owen

Daniel_Roesen · November 13, 2004, 1:56am

>OK, but this doesn't have any effect on your "Listen",
>"NameVirtualHost" and "<VirtualHost>" statements of your httpd.conf,
>"ListenAddress" in sshd.conf, "Bind" in proftpd.conf, "*-source" and
>"listen-on*" in named.conf, [...]
>
True. However, in all of the cases above except named.conf,
names are a perfectly valid substitute for the IP address.

No. Those configs are read at boot-time. Now think about a power
outage recovery. Server comes up but cannot reach DNS when services
are starting up. Boom, your server's services bail out and are dead
in the water. To prevent this, you might fill your /etc/hosts with
the own FQDN-to-IP mappings, but this again has the problem of being
pretty static.

>Not to forget all the IP address based ACLs.
>
I suspect that eventually, we will discover that ADDRESS-based
ACLs simply do not scale to a V6 world, and, you will see support
for other strategies, such as host-name based ACLs.

Layer 3 doesn't know host names. Nor does layer 4. Applications do.
Security requirements do often mandate working access control even
when DNS doesn't work or is compromised.

Regards,
Daniel

Owen_DeLong · November 13, 2004, 7:53am

> OK, but this doesn't have any effect on your "Listen",
> "NameVirtualHost" and "<VirtualHost>" statements of your httpd.conf,
> "ListenAddress" in sshd.conf, "Bind" in proftpd.conf, "*-source" and
> "listen-on*" in named.conf, [...]
>
True. However, in all of the cases above except named.conf,
names are a perfectly valid substitute for the IP address.

No. Those configs are read at boot-time. Now think about a power
outage recovery. Server comes up but cannot reach DNS when services
are starting up. Boom, your server's services bail out and are dead
in the water. To prevent this, you might fill your /etc/hosts with
the own FQDN-to-IP mappings, but this again has the problem of being
pretty static.

Or... Recognizing that you have a dependency on DNS, you include
S10WaitForDns in your rc3.d and don't continue the bootstrap until
DNS is reachable. Of course, if you're all _THAT_ worried about it,
you make your host a secondary for the domains it needs to know
about and have it run a caching resolver that is authoritative for
the local domains which only binds to the localhost port, so, no
problem and not static. Then, you just need to start BIND before
you start those services.

> Not to forget all the IP address based ACLs.
>
I suspect that eventually, we will discover that ADDRESS-based
ACLs simply do not scale to a V6 world, and, you will see support
for other strategies, such as host-name based ACLs.

Layer 3 doesn't know host names. Nor does layer 4. Applications do.
Security requirements do often mandate working access control even
when DNS doesn't work or is compromised.

Security requirements are that you not permit packets that should not be
when DNS is not working. Nothing says the router cannot run a resolver
pass when parsing the ACL or when told to refresh the ACL to translate
the configured names into IP addresses. Nothing precludes a periodic
automatic refresh.

Hope this helps show that these problems can be mitigated in more
scalable ways.

Owen

Henning_Brauer · November 13, 2004, 9:02am

* Owen DeLong <owen@delong.com> [2004-11-13 08:46]:

I suspect that eventually, we will discover that ADDRESS-based
ACLs simply do not scale to a V6 world

which I see as an issue with v6 and not the ACLs.

Henning_Brauer · November 13, 2004, 9:10am

* Owen DeLong <owen@delong.com> [2004-11-13 09:11]:

Or... Recognizing that you have a dependency on DNS, you include
S10WaitForDns in your rc3.d and don't continue the bootstrap until
DNS is reachable.

in my what?
this is just sick, in any case.

>>> Not to forget all the IP address based ACLs.
>>I suspect that eventually, we will discover that ADDRESS-based
>>ACLs simply do not scale to a V6 world, and, you will see support
>>for other strategies, such as host-name based ACLs.
>Layer 3 doesn't know host names. Nor does layer 4. Applications do.
>Security requirements do often mandate working access control even
>when DNS doesn't work or is compromised.
Security requirements are that you not permit packets that should not be
when DNS is not working. Nothing says the router cannot run a resolver
pass when parsing the ACL or when told to refresh the ACL to translate
the configured names into IP addresses. Nothing precludes a periodic
automatic refresh.

this is completely unacceptable and fails the point entirely.

Hope this helps show that these problems can be mitigated in more
scalable ways.

why do the v6 proponents always pretend that they can change everything?
there's a reason for how things are now, and many of them are good
reasons (and some are poor, yes).
v6 should solve
1) the address space problem
2) autoconfiguation

however, by giving this to academics with much too much time on their
hands, v6 transformed into unusable crap, and we are where we are now,
as in, no real world relevance for v6, and it doesn't look like that
will change anytime soon.

face some facts, you are not going to change the way the net works in
such ways.

go back to the drawing board and start cutting out the crap. then v6
(or whatever it might be called then) has a chance.

Iljitsch_van_Beijnum · November 13, 2004, 12:48pm

Yes, because address based access restrictions never get in the way of renumbering in IPv4.

Filtering based on IP addresses is a broken concept.

I'm not a huge fan of sprinkling crypto over everything, but if you want certain people to have access to some stuff and not others, IPsec/SSL are the way to go.

Henning_Brauer · November 13, 2004, 1:38pm

* Iljitsch van Beijnum <iljitsch@muada.com> [2004-11-13 13:48]:

Filtering based on IP addresses is a broken concept.

this arrogance and misguided view of the 'net is probably the main reason
why v6 doesn't work.

Owen_DeLong · November 13, 2004, 5:14pm

FWIW, I think TLS is a cleaner approach than SSL, but, otherwise, I agree
with Iljitsch.

Owen

Christopher_L_Morro1 · November 14, 2004, 3:09am

there are things putting random packets over the network today, trying to
exploit services you might be using, or your customers might be using.
IPSEC everywhere is 'nice' but not horribly practical. SSL is nice, until
your SSL libraries have remotely exploitable DoS or root
vulnerabilities... how many times over the last 12 months has openssl been
upgraded due to 'security' issues?