Subject: Re: [v6ops] Signaling shared addressing and 6to4

From: Arturo Servin <[email-masked]>
Date: Sun, 1 May 2011 19:49:04 -0300

6to4 + CGNs, mmmm, no thanks.

	I like the idea but for a more general or different purpose, not only (or justified) for 6to4.

Regards,
-as

On 29 Apr 2011, at 00:44, Mark Andrews wrote:

> 
> 	Currently in front of ARIN there is a proposal for a /10
> 	which would be shared be network operators for assigning
> 	IPv4 addresses to customers behing CGNs.  This address block
> 	and any other non-RFC 1918 address block used for address
> 	sharing will cause operational problems for 6to4 users.
> 
> 	It would be useful for ISP's to be able to signal when a
> 	address returned by DHCP or PPP is to be shared so that
> 	6to4 and other functionality that depends on unshared
> 	public IPv4 addresses can be disabled.
> 
> 	It would also be useful for a ISP's clients to be able to
> 	signal that they need a unshared public IPv4 address when
> 	there is a mix of shared and unshared IPv4 addresses available
> 	to assign to a customer.
> 
> 	I propose the we allocate DHCP and PPP code points that the
> 	client can set if they desire a unshared address or have
> 	enables a feature that requires a unshared address.  The
> 	default would be to say a shared address is acceptable.
> 	The ISP would set the status of the address in the reply.
> 	The client would then take whatever corrective action
> 	required if they can't get the designed type of address.
> 
> 	Mark
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE:	+61 2 9871 4742		         INTERNET: [email-masked]
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mark Andrews <[email-masked]>
Date: Mon, 02 May 2011 08:59:06 +1000

In message <[email-masked]>, "
George, Wes E [NTK]" writes:
> ------=_NextPart_000_0087_01CC0665.7E631CF0
> Content-Type: text/plain;
> 	charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Bri
> an E Carpenter
> Sent: Friday, April 29, 2011 1:49 AM
> To: Mark Andrews
> Cc: [email-masked]
> Subject: Re: [v6ops] Signaling shared addressing and 6to4
> 
> On 2011-04-29 15:44, Mark Andrews wrote:
> I sincerely hope ARIN will have the common sense to reject this awful idea, b
> ut that is not a v6ops discussion.
> 
> [WEG] PPML is an open list, and the policy is currently in last call. Feel fr
> ee to join the fun.
> http://lists.arin.net/pipermail/arin-ppml/2011-April/020808.html.
> 
> 
> I certainly think that ISPs should tell their customers that they aren't actu
> ally providing Internet service - see RFC 4084.
> [WEG] So in addition to the debacle around "4G" wireless service vs the ITU's
>  standard, now we're going to try our hands at managing
> the marketing about what is and is not Internet service? It's simply not that
>  black-and-white post IPv4 exhaustion. I would bet that
> most customers would prefer being NATed to being told - "sorry, the (IPv4) in
> ternet is full, go away (or go IPv6-only). Oh and by
> the way, replace all of the kit in your house that doesn't support IPv6."

Which is a gross exageration.  You can run dual stack internally.
The only parts that need to be upgraded is those that need to talk
the global Internet.

> That would be for ISPs incapable of supporting IPv6?
> [WEG] You (wrongly) assume that this is completely the ISP's fault (and not c
> ustomer owned CPE), and that simply having IPv6 will
> eliminate the need for supporting IPv4 at all. 
> I will note however that I'm convinced that the brokenness of NAT444 is likel
> y to be IPv6's killer app, so while operationally it'd
> be nice to have a way to manage that brokenness, it's probably better to just
>  get it over with. Also, I think there's no way to
> balance those who believe that they "need" a public IP vs those who *actually
> * do vs the available IPv4 resources - to your later
> point about the "wrong" default.

Sure, I'd like to get it over with and have been asking my ISP about
IPv6 for the last 8 years.

> That said, Mark, I think this is one more idea to add to the "good, but too l
> ittle too late" pile. I can't see it having wide enough
> deployment in a reasonable period of time to matter as far as fixing IPv4 or 
> IPv6 brokenness, and if it does get widely deployed,
> the time to develop and implement it probably should have been spent on more 
> pressing issues (like the underlying brokenness). 

I suspect that most ISP's will still be running IPv4 in 10 years
time.  It will still be useful for the host/router device to know if
it is on a shared address or not.

You say it is a good idea.  Only time will tell if it is too late or
will get used.

> Wes George

---

From: Mark Andrews <[email-masked]>
Date: Mon, 02 May 2011 10:43:13 +1000

In message <[email-masked]>, Arturo Servin wri
> 	I like the idea but for a more general or different purpose, not only (

	I'm sure that there are plenty of senarios, 6to4 is just
	one.

	I've got a voip phone where I need a reasonably stable
	external public address.  The phone gets reconfigured
	whenever the external IPv4 address changes (via
	dhclient-exit-hooks).

	I've also got a tunnel to HE for IPv6 which again needs a
	reasonably stable external public address.  The tunnel gets
	reconfigured whenever the external IPv4 address changes
	(via dhclient-exit-hooks).

	I send traffic destined to 6to4 addressess directly though
	I don't use a 6to4 address.  This works today.  This may
	or may not work with a CGN.  Changing the source address
	of these packets won't hurt.  However this needs to be
	tested when/if I'm behind a CGN and it would be useful to
	know when that happens.

	I have no idea when my ISP will be forced to turn on CGN
	or when they will deliver IPv6 (native or via 6rd).  I do
	know that one doesn't have to put everyone behind a CGN and
	that having a standard method can only help.

	Mark