[mdlug] Looking for IPv6 presenter for LUGWASH

[Michael Mol]

On Fri, Jan 20, 2012 at 5:36 PM, Jay Nugent <jjn at nuge.com> wrote:
> Greets,
> On Fri, 20 Jan 2012, Michael Mol wrote:
>
>>>   I think you mean "static" IP address.
>>
>>
>> No, I mean public IPv4 address. As in, publicly routeable. I'm on
>> Comcast residential, so DHCP, but I have a publicly routable IPv4
>> address (71.205.113.62, at the moment). It just changes every few
>> weeks.
>
>
>   Yes, exactly.  STATIC publicly routable, non-RFC1918 address.  A.k.a.
> 'static'.  As opposed to a 'dynamic' publicly routable non-RFC1918 address
> that changes every few weeks.

So we've established that we're talking about non-RFC1918,
publicly-routable IPv4 addresses. My original point was that Hurricane
Electric's 6in4 tunnels require public IPv4 addresses. That remains
true.

It is irrelevant whether the IPv4 addresses are static or dynamic,
except to the point where you may have downtime on the tunnel if your
IPv4 lease renewal is refused, you get bumped to a different lease,
and the configuration of your tunnel hasn't been updated on their
tserv. (Curiously, on my connection, I tend to be flipped between
different subnets when the IP changes. I wonder if that's related to
network maintenance or some such.)

>  I currently have TWO /25 blocks from my ISP
> (216.144.208/25 and 63.215.167/25).  I *can* live with a lot less so I am
> hoping to negotiate with the new ISP for a block of 32 addrs.

Wow...nice. :) My employer gets a big whopping /29. One's usable IPv4
address space gets kinda narrow down here.

>   And just because your address is served up via DHCP doesn't mean that it
> cannot be 'static' (never changing).  We did that all the time with each of
> the ISP's that I have done consulting work for (half dozen or so of them, so
> far).

Certainly having your IP served up via DHCP doesn't mean it can't be
static. It doesn't force the issue one way or another.

>> My understanding of ADSL is that non-primary* ADSL providers have
>> their traffic routed through the primary's network on a tagged vlan,
>> until it comes out at the ISP's POP. IIRC, I did find an ADSL provider
>> in Seattle which could give me (in Grand Rapids) native IPv6, but my
>> packets would be bouncing across the country.
>
>
>   Coolness!

Cool in that there's an ADSL provider that'd do it! Not so cool for
the latency factor or the amount of AT&T equipment the packets would
have to cover. It's my understanding AT&T's DSL routing architecture
is so overdue for incremental upgrades and layout refactoring, they're
to the stage where it'd be cheaper to replace the whole thing. And
they committed that money bidding on T-Mobile. So I went to Comcast.

I wish more ADSL ISPs would set themselves up to provide IPv6, though.
I think 6rd is fine for a *very* short-term solution, but it'd annoy
the heck out of me. Having my IPv6 address space renumber every time
my IPv4 address changed would be maddening, and I don't want to pay
for business class on a residential connection.

>> * Don't know the exact term, sorry. Primary being the physical owner,
>> non-primary being the ones who lease.
>
>
>   In brief, for those on the list whom have ever wondered:
>
>   The DSL signal is carried over the copper pair to the telephone Central
> Office where it is atteched to a specific physical port on a DSLAM.  The
> DSLAM *may* belong to the Telco, or it *may* belong to a provider.  But
> typically the Telco owns them and leases space.  ISP's subscribe to lease
> space on several DSLAMS in different Central Offices (CO) within a LATA or
> across a specific geographic region.  Some ISP's only support a small number
> of CO's, others lease DSLAM space across the entire state or country.
>
>   The DSLAM is configured to pass your traffic using L2TP (layer 2 Transport
> Layer) packets across an ATM (Asynchronous Transport) "cloud". THE DSLAM
> config states that your physical 'port' belongs to 'X' ISP, what the maximum
> allowed speed will be (1.5 down by 768k up), and routes the packets
> accordingly.  Each ISP (TelnetWW, Provide.net, DigitalRealm.com, WWnet,
> AT&T, etc.) subscribe to a connection off of this ATM cloud to collect the
> traffic from their subscribers.
>
>   The L2TP packets come accross the ATM cloud into the ISP's "concentrator"
> (typically a large Cisco router) where the connection is then authenticated
> using RADIUS.  The RADIUS config tells the concentrator where these packets
> may flow (to private VPN, like AOL) or should they be allowed to reach the
> public Internet.  RADIUS also defines if the customer is 'dynamic' or
> 'static', and how large that static block of addresses is supposed to be.
>
>
>   Well, that's it in a nutshell.  There are many more details involved, but
> this gives a general idea how the process works.
>
>   Enjoy!

That's a very excellent explanation, thanks!

-- 
:wq