Re: IPv6 Confusion

[Mark Andrews <Mark_Andrews () isc org>]

In message <6F7BA817-320B-414F-9811-03B476990800 () virtualized org>, David Conrad
 writes:
> On Feb 17, 2009, at 3:55 PM, Mark Andrews wrote:
> > 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

> Regards,
> -drc
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews () isc org