IPv6 Confusion

Wed Feb 18 05:09:11 UTC 2009

In message <6F7BA817-320B-414F-9811-03B476990800 at 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 at isc.org