Subject: (ngtrans) DSL/Cable IPv4/IPv6 access when ISP performs NAT

From: Pekka Savola <[email-masked]>
Date: Wed, 11 Jul 2001 21:48:10 +0300 (EEST)

Hi,

This might be a little better suited for e.g. [email-masked], but it does
contain some issues ngtrans might find useful, so.. if you feel another
list would be more appropriate, please advise.

I'm curious whether any ISP has provided/tested DSL/Cable(/Dialup) IPv6
access yet?  I remember there has been some work wrt. dialups in Japan,
but I couldn't find any references to this, or some real user access work.

More specifically, I'm interested in ways to provide joint IPv4/IPv6
service.  Cisco is promising support for this at phase 3 (in about a
year), FWIW, but it's unclear whether CPE equipment (e.g. 6xx series) will
be able to run new IOS.

I'll summarize a few scenarios not to bloat the discussion overmuch.

These aren't (this) interesting, because the user can get IPv6
connectivity by other means:

1) ISP gives a static, globally unique IPv4 (use static tunnels, 6to4)
2) ISP gives a dynamic (per session), globally unique IPv4 (6to4)

This is "interesting":

1) ISP gives one or more private-space addresses and NAT's them to one or
more global (perhaps dynamic) IPv4 addresses so that there is no
one-to-one mapping.

This scenario is usually regarded as "tough luck, get a nicer ISP" (by me
too ;-).

Unfortunately RIR's are getting real stingy about address space, and the
scenario is getting more and more common.  One other reason why ISP's do
this is because it allows them to block the users from keeping servers or
providing any (perhaps bandwidth-extensive) services on the cheapo
connection.

In this kind of scenario, IPv6 would be a great value-added service for
the ISP:  static fully networkable IPv6 address block, unlikely that
people keep huge amounts of MP3, Warez servers. etc. would want it for a
few years, being on the cutting edge etc.  I for one would be willing to
pay extra for IPv6 connectivity with a static prefix.

So, when dealing with the NAT scenario it effectively becomes necessary to
get co-operation from a party with a static internal and external address.
In practise this is the ISP, but it could also some lucky bastard for whom
no NAT is being performed.

There appear to be two methods to make this work:
 1) static tunnels using internal addresses to a box with both internal
and external addresses; the said box is allocating /48's or /64's to the
users
 2) if ethernet is being emulated, just plain ol' router advertisements
etc. might work too; I don't think this is a valid scenario.

I've thought on different options for 1) quite a bit, but I'll save them
for the later, if people are interested in this; if this is viewed as
important, this might make a nice informational RFC I guess :-)

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: [email-masked]
Date: Thu, 12 Jul 2001 09:29:03 +0900

>important, this might make a nice informational RFC I guess :-)

	for (1), if you mean that the upstream ISP itself provides tunnel
	endpoint within private address cloud, i guess there's no special needs.

	- setup IPv6-over-IPv4 tunnel within private address cloud, between
		customer DSL modem/router
		IPv6-only router (private side)
	- IPv6-only router would have some sort of connectivity to the outside
	  (maybe a tunnel to other ISPs)

itojun

		 |
		=+=======+== global
		 |	 |
upstream ISP	NAT	IPv6-only router
		 |	 |
		=+=======+== IPv4 private address
		 |
		DSL concentrator
		 |
		 |
customer	DSL modem/router
		 |

---

From: Pekka Savola <[email-masked]>
Date: Thu, 12 Jul 2001 12:32:52 +0300 (EEST)

> customer	DSL modem/router

Exactly like this.

An additional option is that if there is one customer that doesn't have
his IP's natted (e.g. paying extra), he can of course act as an IPv6
backdoor too ;-)

There are some practical considerations.  The tunnel endpoints could be
some combination of:

{DSLModem, HomePC, HomeServer } <=> {ISPRouter, ISPServer, SomeServer}

Some points:

* DSLModem
 - Very few (none?) DSL modems support IPv6 at the moment, and low
end ones (not just the price, e.g. Cisco 67x) probably never.
 - Sometimes owned by the ISP, can't upgrade
 - "Production network" equipment -- you don't want IPv4 to break...
 ==> "the way" in 2-3 years perhaps, not yet.

* HomePC
 - Setting up IPv6 tunnel could be tricky
 - If you have multiple systems, intelligent IPv6 (wireless) gadgets etc.
every one should be configured

* HomeServer
 - E.g. Linux/BSD(/Win2k?) box people often have now acting as a firewall,
NAT box etc. converted to IPv6 router
 - Provides stateless autoconfiguration to all hosts in local lan
 - Often rather flexible configuration options

* ISPRouter
 - Production equipment.  IPv6 software supporting required functions not
really available.  Even if officially released, ISP's would be reluctant
to move to completely new softare too soon.
 ==> production ready perhaps in 2 years

* ISPServer
 - Some Linux/BSD box or a "standard" IPv6 router, why not.
 - Messing up here only messes experimental IPv6

* SomeServer
 - as above
 - trust.  you don't want some guy sniffing your ipv6 http traffic.

==> so practically, the choices might be:
 1) user: HomePC, HomeServer
 2) ISP:  ISPServer

Additional notes:
 - IPv4 addresses should be static (even if allocated via DHCP or the
like) for static tunnels
 - If the IPv4 addresses aren't completely static, ISPServer could obtain
the DHCP mappings from DHCP servers and adjust the tunnels accordingly.
 - This could also be implemented as an internal tunnel broker service
dealing with private IPv4 addresses.