Subject: [v6ops] Signaling shared addressing and 6to4

From: Mark Andrews <[email-masked]>
Date: Fri, 29 Apr 2011 13:44:58 +1000

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]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 29 Apr 2011 07:45:55 +0200 (CEST)

> 	public IPv4 addresses can be disabled.

Do we really need to spend time on this at this point in history? Wouldn't 
it take 2-3 years until this functionality is widely available in the 
field, and then the problem is already gone (IPv4 long since depleted and 
IPv6 being widely deployed)?

I think it's better to have mechanisms autodetect if they're on a shared 
address (or if the tunneling mechanisms they're trying to use actually 
works) and act on this, than to try to handle this through DHCP/PPP.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Apr 2011 17:49:24 +1200

> 	sharing will cause operational problems for 6to4 users.

I sincerely hope ARIN will have the common sense to reject this
awful idea, but that is not a v6ops discussion.
> 	public IPv4 addresses can be disabled.

You mean other functionality like this peer to peer Internet thing
that I'm connected to at work, but unfortunately not at home except
via IPv6?

I certainly think that ISPs should tell their customers that they
aren't actually providing Internet service - see RFC 4084.

> 	there is a mix of shared and unshared IPv4 addresses available

That would be for ISPs incapable of supporting IPv6?
> 	default would be to say a shared address is acceptable.

Wrong default, I think.

> 	required if they can't get the designed type of address.

Like change to a different ISP?

It would be so much more productive to put all that effort into
IPv6 deployment instead of IPv4 kludging.

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Fri, 29 Apr 2011 16:17:28 +1000

In message <[email-masked]>, Mikael Abrah
> IPv6 being widely deployed)?

If a code point was allocated today, it could be used by the DHCP
clients and servers we ship 7 years ago.  It would just be a
configuration change.

None of us know when IPv4 will be die.  We should however make that
process as graceful as possible.  If it comes too late what is the
harm in having a code point allocated?  It can only do good.

> works) and act on this, than to try to handle this through DHCP/PPP.

Which requires lots of changes in lots of protocols and may not be
possible in all of them.

Mark

---

From: Gert Doering <[email-masked]>
Date: Fri, 29 Apr 2011 10:09:45 +0200

Hi,

> harm in having a code point allocated?  It can only do good.

"Waste of human time better spent on IPv6 deployment" comes to mind.

Gert Doering
        -- NetMaster
-- 
did you enable IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: John Curran <[email-masked]>
Date: Fri, 29 Apr 2011 08:37:36 -0400

>   required if they can't get the designed type of address.

V6ops folks - 

  Discussion of the code points for this purpose may be 
  worthwhile, but it is not assured that the proposal in the 
  ARIN region will be adopted. I have also noted to the ARIN 
  community that actual implementation of the /10 IPv4 block 
  for this technical purpose requires consultation with the 
  IAB and IESG, as designation of specialized address blocks
  are traditionally performed by the IANA under IESG authority
  per RFC 2860.  I just wanted to keep everyone apprised of
  where we are with this particular policy and allocation.

Thanks!
/John

John Curran
President and CEO
ARIN

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Fri, 29 Apr 2011 16:03:44 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Friday, April 29, 2011 1:49 AM
To: Mark Andrews
Cc: [email-masked]
Subject: Re: [v6ops] Signaling shared addressing and 6to4

> 	sharing will cause operational problems for 6to4 users.

I sincerely hope ARIN will have the common sense to reject this awful idea, but that is not a v6ops discussion.

[WEG] PPML is an open list, and the policy is currently in last call. Feel free 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 actually 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) internet 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."

That would be for ISPs incapable of supporting IPv6?
[WEG] You (wrongly) assume that this is completely the ISP's fault (and not customer 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 likely 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.

That said, Mark, I think this is one more idea to add to the "good, but too little 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). 

Wes George