> In otherwords ISP's need to enter the 21st century.
Yeah, those stupid, lazy, ISPs. I'm sure they're just sitting around
every day, kicking back, eating Bon Bons(tm), and thinking of all the
new and interesting ways they can burn the vast tracts of ill-gotten
profits they're obviously rolling in.Reality check: change in large scale production networks is hard and
expensive. There needs to be a business case to justify making
substantive changes. You are arguing that ISPs should make changes
without any obvious mechanism to guarantee some return on the
investment necessary to pay for those changes. This is a waste of time.
Adding support to accept dynamic updates is a small
configuration change.
In general, NAT is paid for by the end user, not the network
provider. Migrating to IPv6 on the other hand is paid for entirely by
the network provider. Guess which is easier to make a business case
for?
No. It also requires the end user to also upgrade equipment.
Mind you a lot of that upgrading has already been paid for
by both the ISP and the end user.
I'll most probably need to upgrade to a DOCSIS 3 modem for
native IPv6 support. I own my current modem.
Note that I'm not saying I like the current state of affairs, rather
I'm suggesting that jumping up and down demanding ISPs change because
you think they're stuck in the last century is unlikely to get you
very far. You want a concrete suggestion? Make configuring DDNS on
BIND _vastly_ simpler, scalable to tens or hundreds of thousands of
clients, and manageable by your average NOC staff.
For the reverse namespace we have tcp-self and 6to4-self
we could trivially add a 56-self for ISP's that want to
deploy on the /56 boundary rather than the /48 boundary
that 6to4-self uses. TCP is used as the authenticator
for these updates.
zone "23.2.1.in-addr.arpa" {
type master;
...
update-policy {
grant * tcp-self * PTR;
};
};
TSIG or SIG(0) can be used in the forward direction.
zone "example.net" {
type master;
...
update-policy {
grant * self *;
};
};
It doesn't get much simpler than that.
Mark