Level 3 OC-12 cut in SanFran/Hayw

[Matthew Huff]

We lost a DS3 out of our downtown SF office around 4 hours ago. The Level 3 
master ticket for OC-12 outage is #3020259 and is out of Hayworth. Anyone know 
anything more about this? Getting any info out of level 3 let alone an ETR has 
been challenging.

Re: Blackhole route advertisements by AS14037 of our IP space - please filter them out at your end

[Suresh Ramasubramanian]

And the guy who is doing this is also an XO downstream as I see.. and
I have a feeling he wont like the consequences of what he did .. but
meanwhile, operationally speaking, my 40 million ++ users would be
glad if these fake announcements could get cut off at the knees

srs
Head, Antispam Operations
Outblaze Limited
http://www.outblaze.com

On Thu, Nov 20, 2008 at 10:49 AM, Suresh Ramasubramanian
<[EMAIL PROTECTED]> wrote:
> Hi
>
> Yes we are on the phone with xo - but meanwhile several other
> operators have been picking it up.
>
> As for operational impact - we're Outblaze.com - thats mail.com,
> register.com hosted domains etc, email for 40 million users or so.
> That makes us, lemme see, quite a bit larger than people like Comcast,
> in terms of userbase for email.
>
> I hope that helps the community decide whether or not to accept these
> bogus blackhole prefixes
>
> thanks
> srs
>
> On Thu, Nov 20, 2008 at 10:41 AM, kris foster <[EMAIL PROTECTED]> wrote:
>> On Nov 19, 2008, at 8:43 PM, Suresh Ramasubramanian wrote:
>>
>>> If you see 208.36.123.0/24 being announced from any other prefix than
>>> XO (2828 I guess) please ignore it.  Especially if you see it
>>> announced from 19318 or 14037.
>>>
>>
>> You're unlikely to get any reasonable response or action here. The best
>> course of action is to work through XO. You are their customer, and it is
>> their address space, right?
>>
>> For what it's worth 208.36.123.0/24 was advertised recently but as a
>> community we have no way of knowing the validity of it, or the operational
>> impact.
>>
>> Kris
>> (not speaking as MLC)
>>
>
>
>
> --
> Suresh Ramasubramanian ([EMAIL PROTECTED])
>



-- 
Suresh Ramasubramanian ([EMAIL PROTECTED])

Re: Blackhole route advertisements by AS14037 of our IP space - please filter them out at your end

[Suresh Ramasubramanian]

Hi

Yes we are on the phone with xo - but meanwhile several other
operators have been picking it up.

As for operational impact - we're Outblaze.com - thats mail.com,
register.com hosted domains etc, email for 40 million users or so.
That makes us, lemme see, quite a bit larger than people like Comcast,
in terms of userbase for email.

I hope that helps the community decide whether or not to accept these
bogus blackhole prefixes

thanks
srs

On Thu, Nov 20, 2008 at 10:41 AM, kris foster <[EMAIL PROTECTED]> wrote:
> On Nov 19, 2008, at 8:43 PM, Suresh Ramasubramanian wrote:
>
>> If you see 208.36.123.0/24 being announced from any other prefix than
>> XO (2828 I guess) please ignore it.  Especially if you see it
>> announced from 19318 or 14037.
>>
>
> You're unlikely to get any reasonable response or action here. The best
> course of action is to work through XO. You are their customer, and it is
> their address space, right?
>
> For what it's worth 208.36.123.0/24 was advertised recently but as a
> community we have no way of knowing the validity of it, or the operational
> impact.
>
> Kris
> (not speaking as MLC)
>



-- 
Suresh Ramasubramanian ([EMAIL PROTECTED])

Re: Blackhole route advertisements by AS14037 of our IP space - please filter them out at your end

[kris foster]

On Nov 19, 2008, at 8:43 PM, Suresh Ramasubramanian wrote:


If you see 208.36.123.0/24 being announced from any other prefix than
XO (2828 I guess) please ignore it.  Especially if you see it
announced from 19318 or 14037.



You're unlikely to get any reasonable response or action here. The  
best course of action is to work through XO. You are their customer,  
and it is their address space, right?


For what it's worth 208.36.123.0/24 was advertised recently but as a  
community we have no way of knowing the validity of it, or the  
operational impact.


Kris
(not speaking as MLC)

Re: Blackhole route advertisements by AS14037 of our IP space - please filter them out at your end

[Suresh Ramasubramanian]

If you see 208.36.123.0/24 being announced from any other prefix than
XO (2828 I guess) please ignore it.  Especially if you see it
announced from 19318 or 14037.

On Thu, Nov 20, 2008 at 9:38 AM, Suresh Ramasubramanian
<[EMAIL PROTECTED]> wrote:
> These routes are also being injected by another AS belonging to
> Rackvibe - AS19318
>
> This is the guy from rackvibe who said he'd blackhole us because we
> blocked him for hosting spammers.
>
> RNOCHandle: GC373-ARIN
> RNOCName:   Czupryna, Gregg
> RNOCPhone:  +1-201-605-1425
> RNOCEmail:  [EMAIL PROTECTED]
>
> RTechHandle: GC373-ARIN
> RTechName:   Czupryna, Gregg
> RTechPhone:  +1-201-605-1425
> RTechEmail:  [EMAIL PROTECTED]
>
>  Network  Next HopMetric LocPrf Weight Path
> *>i 208.36.123.0 209.123.44.153100  0 8001 19318
> 14037 i
>
> telnet route-server.quagga.net port 2605 shows various ASNs
> exclusively getting blackhole routes from AS19318
>
>
>
> On Thu, Nov 20, 2008 at 8:03 AM, Suresh Ramasubramanian
> <[EMAIL PROTECTED]> wrote:
>> Hi
>>
>> We blocked some prefixes belonging to AS14037 (rackvibe llc) due to
>> their hosting spammers.
>>
>> Rackvibe decided to nullroute us back in reply - thats up to them I guess
>>
>> Only they're dumb enough to inject these blackhole announcements into
>> the cloud, and various other networks are picking up on these
>> announcements
>>
>> TIA for filtering these out at your end
>>
>> Our IPs are below - at least 208.36.123/24 seems to be announced as a
>> blackhole route by rackvibe -
>>
>> 205.158.62.0/24
>> 208.36.123.0/24
>> 203.86.166.0/24
>> 65.49.50.0/24
>> 65.49.50.0/24
>> 64.71.166.192/27
>> 64.62.181.80/28
>>
>> srs
>>
>> Paths: (7 available, best #7, table Default-IP-Routing-Table)
>>  Not advertised to any peer
>>  16150 6939 19318 14037
>>217.75.96.60 from 217.75.96.60 (217.75.96.60)
>>  Origin IGP, metric 0, localpref 100, valid, external
>>  Community: 16150:63392 16150:65320 16150:65426
>>   1103 1273 19318 14037
>>193.0.0.56 from 193.0.0.56 (193.0.0.56)
>>  Origin IGP, localpref 100, valid, external
>>  Community: 1103:1000 1273:21000 1273:21971 14037:6855 19318:999
>> 19318:4000 19318:6855 19318:40012 21698:999 21698:4000 21698:6855
>>  3277 3216 1273 19318 14037
>>194.85.4.55 from 194.85.4.55 (194.85.4.16)
>>  Origin IGP, localpref 100, valid, external
>>  Community: 1273:21000 1273:21971 3216:3000 3216:3001 3277:3216
>> 14037:6855 19318:999 19318:4000 19318:6855 19318:40012 21698:999
>> 21698:4000 21698:6855
>>  812 19318 14037
>>
>
>
>
> --
> Suresh Ramasubramanian ([EMAIL PROTECTED])
>



-- 
Suresh Ramasubramanian ([EMAIL PROTECTED])

Re: Blackhole route advertisements by AS14037 of our IP space - please filter them out at your end

[Suresh Ramasubramanian]

These routes are also being injected by another AS belonging to
Rackvibe - AS19318

This is the guy from rackvibe who said he'd blackhole us because we
blocked him for hosting spammers.

RNOCHandle: GC373-ARIN
RNOCName:   Czupryna, Gregg
RNOCPhone:  +1-201-605-1425
RNOCEmail:  [EMAIL PROTECTED]

RTechHandle: GC373-ARIN
RTechName:   Czupryna, Gregg
RTechPhone:  +1-201-605-1425
RTechEmail:  [EMAIL PROTECTED]

  Network  Next HopMetric LocPrf Weight Path
*>i 208.36.123.0 209.123.44.153100  0 8001 19318
14037 i

telnet route-server.quagga.net port 2605 shows various ASNs
exclusively getting blackhole routes from AS19318



On Thu, Nov 20, 2008 at 8:03 AM, Suresh Ramasubramanian
<[EMAIL PROTECTED]> wrote:
> Hi
>
> We blocked some prefixes belonging to AS14037 (rackvibe llc) due to
> their hosting spammers.
>
> Rackvibe decided to nullroute us back in reply - thats up to them I guess
>
> Only they're dumb enough to inject these blackhole announcements into
> the cloud, and various other networks are picking up on these
> announcements
>
> TIA for filtering these out at your end
>
> Our IPs are below - at least 208.36.123/24 seems to be announced as a
> blackhole route by rackvibe -
>
> 205.158.62.0/24
> 208.36.123.0/24
> 203.86.166.0/24
> 65.49.50.0/24
> 65.49.50.0/24
> 64.71.166.192/27
> 64.62.181.80/28
>
> srs
>
> Paths: (7 available, best #7, table Default-IP-Routing-Table)
>  Not advertised to any peer
>  16150 6939 19318 14037
>217.75.96.60 from 217.75.96.60 (217.75.96.60)
>  Origin IGP, metric 0, localpref 100, valid, external
>  Community: 16150:63392 16150:65320 16150:65426
>   1103 1273 19318 14037
>193.0.0.56 from 193.0.0.56 (193.0.0.56)
>  Origin IGP, localpref 100, valid, external
>  Community: 1103:1000 1273:21000 1273:21971 14037:6855 19318:999
> 19318:4000 19318:6855 19318:40012 21698:999 21698:4000 21698:6855
>  3277 3216 1273 19318 14037
>194.85.4.55 from 194.85.4.55 (194.85.4.16)
>  Origin IGP, localpref 100, valid, external
>  Community: 1273:21000 1273:21971 3216:3000 3216:3001 3277:3216
> 14037:6855 19318:999 19318:4000 19318:6855 19318:40012 21698:999
> 21698:4000 21698:6855
>  812 19318 14037
>



-- 
Suresh Ramasubramanian ([EMAIL PROTECTED])

Re: Google/Yahoo - Geo-Location Issues

[Jasper Bryant-Greene]

Ditto for Google to me please, we are also having geo-location issues  
with various google.* domains.


Thanks,
Jasper

On 20/11/2008, at 4:06 PM, Mark Tinka wrote:


Hi all.

Grateful if someone from Google and Yahoo can contact me
off-list re: some geo-location issues with their web sites,
our side of the world.

E-mail to the 'noc@' addresses seem to have > /dev/null'ed.

Cheers,

Mark.


--
Jasper Bryant-Greene
Network Engineer, Unleash

ddi: +64  3 978 1222
mob: +64 21 129 9458

Google/Yahoo - Geo-Location Issues

[Mark Tinka]

Hi all.

Grateful if someone from Google and Yahoo can contact me 
off-list re: some geo-location issues with their web sites, 
our side of the world.

E-mail to the 'noc@' addresses seem to have > /dev/null'ed.

Cheers,

Mark.


signature.asc
Description: This is a digitally signed message part.

Blackhole route advertisements by AS14037 of our IP space - please filter them out at your end

[Suresh Ramasubramanian]

Hi

We blocked some prefixes belonging to AS14037 (rackvibe llc) due to
their hosting spammers.

Rackvibe decided to nullroute us back in reply - thats up to them I guess

Only they're dumb enough to inject these blackhole announcements into
the cloud, and various other networks are picking up on these
announcements

TIA for filtering these out at your end

Our IPs are below - at least 208.36.123/24 seems to be announced as a
blackhole route by rackvibe -

205.158.62.0/24
208.36.123.0/24
203.86.166.0/24
65.49.50.0/24
65.49.50.0/24
64.71.166.192/27
64.62.181.80/28

srs

Paths: (7 available, best #7, table Default-IP-Routing-Table)
  Not advertised to any peer
  16150 6939 19318 14037
217.75.96.60 from 217.75.96.60 (217.75.96.60)
  Origin IGP, metric 0, localpref 100, valid, external
  Community: 16150:63392 16150:65320 16150:65426
   1103 1273 19318 14037
193.0.0.56 from 193.0.0.56 (193.0.0.56)
  Origin IGP, localpref 100, valid, external
  Community: 1103:1000 1273:21000 1273:21971 14037:6855 19318:999
19318:4000 19318:6855 19318:40012 21698:999 21698:4000 21698:6855
  3277 3216 1273 19318 14037
194.85.4.55 from 194.85.4.55 (194.85.4.16)
  Origin IGP, localpref 100, valid, external
  Community: 1273:21000 1273:21971 3216:3000 3216:3001 3277:3216
14037:6855 19318:999 19318:4000 19318:6855 19318:40012 21698:999
21698:4000 21698:6855
  812 19318 14037

Re: Origin ASN seen vs Origin ASN in Whois Records Report?

[Bill Woodcock]

  On Wed, 19 Nov 2008, Heather Schiller wrote:
> I don't know if a report like this already exists, but I haven't been able
> to find one.  Can someone (CIDR Report? BGPMon? PCH?) offer a report that
> shows the discrepencies in Origin ASN according to the whois records, and
> routes in the [global/public] routing table?  

I'm pretty sure that we don't already generate that, though I'm checking 
to make sure.  We do have all the necessary data sources already in our 
database and updated in real-time, so no problem to generate it.  May take 
a day or two.

-Bill

Origin ASN seen vs Origin ASN in Whois Records Report?

[Heather Schiller]

I don't know if a report like this already exists, but I haven't been 
able to find one.  Can someone (CIDR Report? BGPMon? PCH?) offer a 
report that shows the discrepencies in Origin ASN according to the whois 
records, and routes in the [global/public] routing table?  Publishing it 
on some regular interval would be even better.


ARIN makes available a list of prefixes with OriginAS.  I don't know if 
other RIR's do.


ftp://ftp.arin.net/pub/originAS/

To be clear.  I want a list of the prefixes where the actual origin ASN 
seen does not match the one in the whois record.  Inconsistent Origin is 
fair game here.  As a transit provider I'm interested in seeing what 
prefixes I am transiting for my customers that have this discrepancy, so 
something that shows the full path as part of the results would be most 
helpful.


Thanks,
--Heather

--

 Heather Schiller   Verizon Business
 Customer Security  1.800.900.0241
 IP Address Management  [EMAIL PROTECTED]
=

Re: IPv6 routing /48s

[Jack Bates]

Mike Leber wrote:

We don't operate any 6to4 gateways.


This I suspected, and actually took as evidence based on the results 
from traceroutes.


However, what is likely happening is a random 6to4 gateway operator may 
have seen fit to rate limit or filter ICMP.


This may very well be true. I have nothing but love for he.net. However, 
the anycast nature of 6to4 does have it's issues. This was just a 
passing example that I noticed. Packets go through the network, but your 
network couldn't send ICMPv6 back. Actually not a concern for me, but I 
doubt it's the only 6to4 issue seen across the network.


To properly diagnose 6to4 problems you potentially need as many as 4 
traceroutes, IPv6 traceroutes from the source and destination endpoints 
and a IPv4 traceroutes to the 6to4 gateway addresses from the source and 
destination endpoint.  There a few other tips I'm forgetting at the 
moment, however if you send us email (to [EMAIL PROTECTED]) we will make sure 
to research it thoroughly.


Will do. Not that I care, but might be something you'll want to check 
into anyways.


Because 6to4 gateways are *anycast* the gateways you use in any part of 
the world in any part of a specific network may be different.


This makes debugging it "interesting".



Definitely, and another reason I am heavily against 6to4 except in cases 
where it's absolutely necessary.


Jack, it seems you are saying traffic passes end to end just fine, you 
just don't get ICMP responses from some of the hops in the middle.  Is 
this correct?


Correct, traceroute and ping find a void on the 2 routers I pass before 
I hit NTT's network in the test case I was doing. I haven't tested this 
in 1/2 a week, though.


If you would like, please send email to [EMAIL PROTECTED] with the detail 
regarding what you are seeing with all of the endpoint information and 
the traceroutes and we will work from our side to see where the 
"interesting" 6to4 gateway is that is affecting your traceroute.  We 
will probably also need you to have access to the destination side as well.


Will do. Be abit. The "interesting" part is primarily what it was 
mentioned. Though in another response I agreed that anyone using IPv6 
from an end network should consider have 6to4 relays so as not to depend 
 on someone else. In some cases, though, it's just not practical.


FYI: Outside of testing, my link to he.net was to take what little 6to4 
traffic I had on the network to non-6to4 addresses and give it a better 
chance. My nearest IPv4 anycast 6to4 was beyond horrid (major 
isolation). Heaviest traffic load appears to be p2p to teredo destinations.



Jack

Re: IPv6 routing /48s

[Christopher Morrow]

On Wed, Nov 19, 2008 at 6:03 PM, Jack Bates <[EMAIL PROTECTED]> wrote:
> Christopher Morrow wrote:
>>
>> 6to4 v6 addrs are just regular v6 addrs as far as the network is
>> concerned. if you put a 6to4 addr on your server you are saying that
>> you don't have native v6 transport to that host(s) and that you are
>> reachable via the 6to4 tunnel your host presumably has configured.
>>
>
> Sure it's just another address, except the anycast portion of it for dealing
> with tunnels. It's also usually set to a different label and priority in
> windows prefix policies (and at least some linux setups). I was referring to
> the matter of if a windows box will even choose to use 6to4.

sure... address selection on new connections, standard ipv6 foo for
end-hosts. routers in the middle don't care, they route to the /16
route for 2002::/16, or they route to 192.88.99.0/24 ... anycast'd on
their respective sides of the version#.

>
>> 6to4 is just an ip, 128bits long, but an ip... no differentiation is
>> made in the network for 6to4 vs 'normal v6'... unless someone's
>> putting up acls, or blackholing 6to4's /16, of course.
>>
>
> Windows and several other end systems use prefix policies to determine if
> they use IPv6 or IPv4 and even when using IPv6, if they should use the 6to4
> tunnel or not.
>

right, normal address selection rules.

>> can you explain this a little more? is it possible your v6 packets hit
>> something like 6pe inside HE and exit to NTT without hitting a
>>
>
> If a router does not a) know how to encapsulate 6to4 and send it over ipv4

routers in the middle shouldn't/won't do this.. once it's encap'd it
rides (on v4) to the 192.88.99.1 device that does the 4->6 majics,
then on to the v6 destination where it rides back to the 'local'
2002::/16 endpoint where 6->4 encap majics happen then over the v4 to
you again.

> to the destination or b) know how to reach a 6to4 anycast address where the
> packet can be encapsulated into IPv4, the packet is going to get dropped. Of
> course, you could be right. he.net could be purposefully not sending icmp
> replies back to 6to4 addresses for other reasons while replying to my
> non-6to4 addresses. I hesitate to say filter, as it does push the 6to4
> sourced packets on to other networks.

hopefully mike's message gets it worked out :)
-chris

Re: IPv6 routing /48s

[Mike Leber]

Christopher Morrow wrote:
>Jack Bates wrote:

A good example is that traceroutes through my he.net tunnel using 6to4
source addresses do not get replies through he.net's network, presumably due
to their routers not being 6to4 aware and having no route to respond.


can you explain this a little more? is it possible your v6 packets hit
something like 6pe inside HE and exit to NTT without hitting a


(Chris thank you for automatically going into customer service mode :)

A bunch of background first, then some questions to help diagnose this 
specific case.


We don't filter 6to4 in any way.

We don't run 6PE.

We don't operate any 6to4 gateways.

We've been considering it carefully, and haven't taken the plunge. 
There is sort of a "routing the whole Internet for free" aspect that 
will occur as v6 takes off and it's not clear how one manages that (i.e. 
If you do it in the beginning until people depend on it and traffic 
grows to 100 Gbps and you no longer can afford to do it for free, do you 
stop?  What about all the IPv4 traffic traveling directly between 6to4 
gateways on IPv4?  abuse, security, man in the middle by definition, etc).


This means any 6to4 gateway action is happening on somebody's 6to4 
gateway not operated by us.


There are people that are using 6to4 on our network that works just 
fine.  You can reach several 6to4 gateways on both IPv4 and IPv6 via our 
network.


However, what is likely happening is a random 6to4 gateway operator may 
have seen fit to rate limit or filter ICMP.


To properly diagnose 6to4 problems you potentially need as many as 4 
traceroutes, IPv6 traceroutes from the source and destination endpoints 
and a IPv4 traceroutes to the 6to4 gateway addresses from the source and 
destination endpoint.  There a few other tips I'm forgetting at the 
moment, however if you send us email (to [EMAIL PROTECTED]) we will make sure 
to research it thoroughly.


Because 6to4 gateways are *anycast* the gateways you use in any part of 
the world in any part of a specific network may be different.


This makes debugging it "interesting".


Responses pick up again after picking up a network such as NTT that is 6to4
aware. My 2001:: addressing works just fine the entire route.


'6to4 aware' doesn't compute...


Jack, it seems you are saying traffic passes end to end just fine, you 
just don't get ICMP responses from some of the hops in the middle.  Is 
this correct?


If you would like, please send email to [EMAIL PROTECTED] with the detail 
regarding what you are seeing with all of the endpoint information and 
the traceroutes and we will work from our side to see where the 
"interesting" 6to4 gateway is that is affecting your traceroute.  We 
will probably also need you to have access to the destination side as well.


Mike.

--
+ H U R R I C A N E - E L E C T R I C +
| Mike LeberWholesale IPv4 and IPv6 Transit  510 580 4100 |
| Hurricane Electric   AS6939 |
| [EMAIL PROTECTED] Internet Backbone & Colocation  http://he.net |
+-+

Re: IPv6 routing /48s

[Jack Bates]

Christopher Morrow wrote:

6to4 v6 addrs are just regular v6 addrs as far as the network is
concerned. if you put a 6to4 addr on your server you are saying that
you don't have native v6 transport to that host(s) and that you are
reachable via the 6to4 tunnel your host presumably has configured.



Sure it's just another address, except the anycast portion of it for 
dealing with tunnels. It's also usually set to a different label and 
priority in windows prefix policies (and at least some linux setups). I 
was referring to the matter of if a windows box will even choose to use 
6to4.



6to4 is just an ip, 128bits long, but an ip... no differentiation is
made in the network for 6to4 vs 'normal v6'... unless someone's
putting up acls, or blackholing 6to4's /16, of course.



Windows and several other end systems use prefix policies to determine 
if they use IPv6 or IPv4 and even when using IPv6, if they should use 
the 6to4 tunnel or not.



can you explain this a little more? is it possible your v6 packets hit
something like 6pe inside HE and exit to NTT without hitting a



If a router does not a) know how to encapsulate 6to4 and send it over 
ipv4 to the destination or b) know how to reach a 6to4 anycast address 
where the packet can be encapsulated into IPv4, the packet is going to 
get dropped. Of course, you could be right. he.net could be purposefully 
not sending icmp replies back to 6to4 addresses for other reasons while 
replying to my non-6to4 addresses. I hesitate to say filter, as it does 
push the 6to4 sourced packets on to other networks.



Jack

Re: IPv6 routing /48s

[Nathan Ward]

On 20/11/2008, at 11:05 AM, Jack Bates wrote:


Nathan Ward wrote:
The problem here is XPSP2/Vista assuming that non-RFC1918 =  
unfiltered/unNATed for the purposes of 6to4.
Well, deeper problem is that they're using 6to4 on an end host I  
suppose - it's supposed to be used on routers.


While I don't doubt that the 6to4 is broken in such circumstances,  
how many IPv6 content providers are using 6to4 addressing and not  
2001:: addressing? 6to4 by default on xp and vista, in my  
experience, is only used if a) talking to another 6to4 address or b)  
there is no IPv4 address available.


IPv6 will be used in preference to IPv4 if it is available. If 6to4 is  
the only IPv6 connectivity then it will be used. See RFC3484.  
Preference of IPv4 is 10, 6to4 is 30.


Things are a bit different with Teredo.. In Vista, if Teredo is the  
only IPv6 connectivity available, WSAConnectByName will not send  
queries for  - obviously Teredo can still be used if the  
application does its own name resolution and opens sockets by INET6  
address, not name.
This Teredo behaviour is not documented in an RFC anywhere I don't  
believe, it is Windows specific.


6to4 never seemed like a viable method for content providing, though  
its use at the eyeball layer is somewhat iffy given that it's  
primary use is for other 6to4 addresses. If prefix policies are  
altered to use it for 2001:: addressing, problems start arising  
quickly.


Right, so, because of how RFC3484 works the above is largely invalid.

Because of RFC3484, putting 6to4 addresses on content is actually  
quite a good idea. It means that hosts with 6to4 connectivity only  
will not have to go via an RFC3068 (192.88.99.1) relay - they will go  
direct over an IPv4 best path between their 6to4 router and yours.


This works best if RFC3484 is widely deployed - it is, however it does  
not exist on OS X. Because of this, if you do this you may find OS X  
clients visiting your content on a 6to4 address when they have native  
connectivity, or vice versa.


So.. stuff to play with, and please go encourage Apple to do RFC3484  
if you are a big customer of theirs.


A good example is that traceroutes through my he.net tunnel using  
6to4 source addresses do not get replies through he.net's network,  
presumably due to their routers not being 6to4 aware and having no  
route to respond. Responses pick up again after picking up a network  
such as NTT that is 6to4 aware. My 2001:: addressing works just fine  
the entire route.


No, he.net does not have a 6to4 relay. If they did it would be used by  
a very large number of networks as he.net is fairly well peered.  
Because of that, the traffic would be quite high, and any relay  
deployment there would have to be managed quite carefully.


I'm sure there's quite a few networks that aren't 6to4 aware,  
hindering 6to4 connectivity to non-6to4 addresses.



6to4 does not require networks to be 6to4 aware - the Internet has  
many public 6to4 relays available.


Note though that most end user IPv6 hosts have a 6to4 relay within 3  
IPv6 hops. This is easy to calculate - throw up an  pointing only  
to a 2002::/16 address, and look at the HLIM of the IPv6 header (not  
the IPv4 header). You will see that it is generally between 124 and  
128, or 60 and 64.

(Some hosts start at 128, some 64. Few start at much else it seems.)
I did some work looking at IPv6 adoption using Bittorrent DHT to talk  
to large numbers of peers without downloading any content, this was  
one of the interesting points that fell out of that work.


Content providers wanting to put  records on things should run  
6to4 relays until IPv4-only networks are a thing of the past. If they  
don't, they'll have to rely on third party relays that might not work.


--
Nathan Ward

Re: Quagga on Xen or VMWare etc

[Vicky Shrestha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Nov 20, 2008, at 02:31 AM, David Curran wrote:

Can anyone provide direction (anecdotal or otherwise) on the use of  
Quagga

in a virtual environment for route servers?


We are running it as route collectors in a virtual environment.



Thanks



Regards,


Vicky Shrestha



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iQEcBAEBAgAGBQihAAoJEGi4SIJCvhMLVbMIAI8J7Zmdmv8/sjVpoZqHpV/e
X3AQrwTwgccEk/K/Z19akON3vavLHygu+SGuMvoE9bxONYi1aVrxdY5S98cnOFU/
B8GLZBRqjf/QlBEHfuFFYo/JaqM2bi0t+ml6Uchbzdzf/vDDdRv09cz6DsGoPKXr
IRbQfQ90khgtmvlXq4CV1s1NKYh/KAwoAAo+ETEtK9worsfyngGV6Ovuerl/bbVJ
d8CwtGyzwNKv+BrtWQ2WHK6JQXW6+WwYce6/ylspRciQOGxVzO0LQ3ZvnX1+LZM0
v4cD6CO0vWW2hIKDX+xG/IIpbNVIS54oWlRqZMC3LtUpoacePY0S+Q2VBgwWBos=
=P0B3
-END PGP SIGNATURE-

Re: IPv6 routing /48s

[Jack Bates]

Michael Sinatra wrote:
If your reference to 2001:: addressing simply means "non-tunneled, 
globally routable IPv6 addressing," then I suppose it is okay.  But 
please note that there is now a lot of native (non-tunneled), globally 
routable IPv6 addressing that is outside of 2001::/16.  ARIN, for 
example, is allocating blocks out of 2607::/16 and there are quite a 
large number of prefixes elsewhere in the designated globally-routable 
2000::/3 that are *not* 6to4 addresses.




heh, these days, lots of it is still tunneled, though through more 
conventional means. But yes, I should have been more clear. Just too 
used to seeing 2001::/16 and too lazy to figure out the proper 
terminology (The original topic is something I've been heavily testing 
lately while I figure out how closely I can get to customer edges and 
how they will react).


The reason I bring this up is that I have already seen certain 
applications, such as one for registering  records for DNS servers 
in a certain TLD, that don't allow anything other than 2001::/16. 
(Fortunately that application was fixed quickly when those responsible 
were notified.)  Just making sure others aren't careening toward making 
the same mistake.


Agreed, and thanks for correcting my post. Would hate for others to take 
my offhanded comments on addressing and use them in production apps.



Jack

Re: IPv6 routing /48s

[Christopher Morrow]

On Wed, Nov 19, 2008 at 5:05 PM, Jack Bates <[EMAIL PROTECTED]> wrote:
> Nathan Ward wrote:
>>
>> The problem here is XPSP2/Vista assuming that non-RFC1918 =
>> unfiltered/unNATed for the purposes of 6to4.
>> Well, deeper problem is that they're using 6to4 on an end host I suppose -
>> it's supposed to be used on routers.
>>
>
> While I don't doubt that the 6to4 is broken in such circumstances, how many
> IPv6 content providers are using 6to4 addressing and not 2001:: addressing?

6to4 v6 addrs are just regular v6 addrs as far as the network is
concerned. if you put a 6to4 addr on your server you are saying that
you don't have native v6 transport to that host(s) and that you are
reachable via the 6to4 tunnel your host presumably has configured.

Content providers MIGHT put 6to4 addrs on their servers so that they
appear to be 'closer' to their clients, or so they might better
control the pathing between client/server... but that's really no
different than a non-6to4 addr as far as the applications and network
are concerned.

> 6to4 never seemed like a viable method for content providing, though its use

it doesn't seem clear that 6to4 buys the content provider much on
their side of the pipe, sure.

> at the eyeball layer is somewhat iffy given that it's primary use is for
> other 6to4 addresses. If prefix policies are altered to use it for 2001::
> addressing, problems start arising quickly.

6to4 is just an ip, 128bits long, but an ip... no differentiation is
made in the network for 6to4 vs 'normal v6'... unless someone's
putting up acls, or blackholing 6to4's /16, of course.

> A good example is that traceroutes through my he.net tunnel using 6to4
> source addresses do not get replies through he.net's network, presumably due
> to their routers not being 6to4 aware and having no route to respond.

can you explain this a little more? is it possible your v6 packets hit
something like 6pe inside HE and exit to NTT without hitting a

> Responses pick up again after picking up a network such as NTT that is 6to4
> aware. My 2001:: addressing works just fine the entire route.
>

'6to4 aware' doesn't compute...

-chris

RE: IPv6 routing /48s

[TJ]

Yes, always worth reminding people:
2000::/3 is the currently active "Global Unicast" pool ... and that
doesn't mean native IPv6

(2002::/16 = 6to4, 2001::/32 = Teredo ... ISATAP may be in play, and
not discretely indicated in prefix side of address
... and non-auto tunnels cold be mentioned here as well,
using global-scope prefixes )


Back to the topic at hand, and in the subject line, global routing of
arbitrary /48s is far from guaranteed.
/32 is the default cutoff  (routing for /35s probably pretty
reliable as well)
Up to /48s for Critical Infra / Micro-Allocations and PI-designated
blocks
... anything else AFAIK is quite possibly troublesome today.

/TJ


>-Original Message-
>From: Michael Sinatra [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, November 19, 2008 4:16 PM
>To: Jack Bates
>Cc: nanog list
>Subject: Re: IPv6 routing /48s
>
>On 11/19/08 14:05, Jack Bates wrote:
>> Nathan Ward wrote:
>>> The problem here is XPSP2/Vista assuming that non-RFC1918 =
>>> unfiltered/unNATed for the purposes of 6to4.
>>> Well, deeper problem is that they're using 6to4 on an end host I
>>> suppose - it's supposed to be used on routers.
>>>
>>
>> While I don't doubt that the 6to4 is broken in such circumstances, how
>> many IPv6 content providers are using 6to4 addressing and not 2001::
>> addressing?
>
>[other references to 2001:: addressing snipped]
>
>I hope I am not being t picky here, and I realize this is not part of
>your main point...
>
>If your reference to 2001:: addressing simply means "non-tunneled, globally
>routable IPv6 addressing," then I suppose it is okay.  But please note that
>there is now a lot of native (non-tunneled), globally routable IPv6
>addressing that is outside of 2001::/16.  ARIN, for example, is allocating
>blocks out of 2607::/16 and there are quite a large number of prefixes
>elsewhere in the designated globally-routable
>2000::/3 that are *not* 6to4 addresses.
>
>The reason I bring this up is that I have already seen certain
applications,
>such as one for registering  records for DNS servers in a certain TLD,
>that don't allow anything other than 2001::/16.
>(Fortunately that application was fixed quickly when those responsible were
>notified.)  Just making sure others aren't careening toward making the same
>mistake.
>
>michael

Re: Quagga on Xen or VMWare etc

[Joel Jaeggli]

David Curran wrote:
> Can anyone provide direction (anecdotal or otherwise) on the use of Quagga
> in a virtual environment for route servers?

I run it in a real environment on a virtual machine (as a route
reflector)...

> Thanks
> 

RE: IPv6 routing /48s

[TJ]

Just for the record, I like my host being the degenerate case of "6to4 site
+ site router all in one".
This makes my life much easier, as I frequently need IPv6 connectivity and
frequently have a public IP(v4) address (EVDO, FTW).

Having said that - what applies to me may well not be the common case.

(Just wanted to state this in case MS is listening and was thinking about
removing the functionality.  I think the right approach is to detect the
failure (s) when they occur, not to remove the functionality)


/TJ


>-Original Message-
>From: Jack Bates [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, November 19, 2008 4:05 PM
>To: Nathan Ward
>Cc: nanog list
>Subject: Re: IPv6 routing /48s
>
>Nathan Ward wrote:
>> The problem here is XPSP2/Vista assuming that non-RFC1918 =
>> unfiltered/unNATed for the purposes of 6to4.
>> Well, deeper problem is that they're using 6to4 on an end host I
>> suppose
>> - it's supposed to be used on routers.
>>
>
>While I don't doubt that the 6to4 is broken in such circumstances, how many
>IPv6 content providers are using 6to4 addressing and not 2001::
>addressing? 6to4 by default on xp and vista, in my experience, is only used
>if a) talking to another 6to4 address or b) there is no IPv4 address
>available.
>
>6to4 never seemed like a viable method for content providing, though its
use
>at the eyeball layer is somewhat iffy given that it's primary use is for
>other 6to4 addresses. If prefix policies are altered to use it for
>2001:: addressing, problems start arising quickly.
>
>A good example is that traceroutes through my he.net tunnel using 6to4
>source addresses do not get replies through he.net's network, presumably
due
>to their routers not being 6to4 aware and having no route to respond.
>Responses pick up again after picking up a network such as NTT that is 6to4
>aware. My 2001:: addressing works just fine the entire route.
>
>I'm sure there's quite a few networks that aren't 6to4 aware, hindering
>6to4 connectivity to non-6to4 addresses.
>
>Jack

Re: IPv6 routing /48s

[Michael Sinatra]

On 11/19/08 14:05, Jack Bates wrote:

Nathan Ward wrote:
The problem here is XPSP2/Vista assuming that non-RFC1918 = 
unfiltered/unNATed for the purposes of 6to4.
Well, deeper problem is that they're using 6to4 on an end host I 
suppose - it's supposed to be used on routers.




While I don't doubt that the 6to4 is broken in such circumstances, how 
many IPv6 content providers are using 6to4 addressing and not 2001:: 
addressing? 


[other references to 2001:: addressing snipped]

I hope I am not being t picky here, and I realize this is not part 
of your main point...


If your reference to 2001:: addressing simply means "non-tunneled, 
globally routable IPv6 addressing," then I suppose it is okay.  But 
please note that there is now a lot of native (non-tunneled), globally 
routable IPv6 addressing that is outside of 2001::/16.  ARIN, for 
example, is allocating blocks out of 2607::/16 and there are quite a 
large number of prefixes elsewhere in the designated globally-routable 
2000::/3 that are *not* 6to4 addresses.


The reason I bring this up is that I have already seen certain 
applications, such as one for registering  records for DNS servers 
in a certain TLD, that don't allow anything other than 2001::/16. 
(Fortunately that application was fixed quickly when those responsible 
were notified.)  Just making sure others aren't careening toward making 
the same mistake.


michael

Quagga on Xen or VMWare etc

[David Curran]

Can anyone provide direction (anecdotal or otherwise) on the use of Quagga
in a virtual environment for route servers?

Thanks

Re: IPv6 routing /48s

[Jack Bates]

Nathan Ward wrote:
The problem here is XPSP2/Vista assuming that non-RFC1918 = 
unfiltered/unNATed for the purposes of 6to4.
Well, deeper problem is that they're using 6to4 on an end host I suppose 
- it's supposed to be used on routers.




While I don't doubt that the 6to4 is broken in such circumstances, how 
many IPv6 content providers are using 6to4 addressing and not 2001:: 
addressing? 6to4 by default on xp and vista, in my experience, is only 
used if a) talking to another 6to4 address or b) there is no IPv4 
address available.


6to4 never seemed like a viable method for content providing, though its 
use at the eyeball layer is somewhat iffy given that it's primary use is 
for other 6to4 addresses. If prefix policies are altered to use it for 
2001:: addressing, problems start arising quickly.


A good example is that traceroutes through my he.net tunnel using 6to4 
source addresses do not get replies through he.net's network, presumably 
due to their routers not being 6to4 aware and having no route to 
respond. Responses pick up again after picking up a network such as NTT 
that is 6to4 aware. My 2001:: addressing works just fine the entire route.


I'm sure there's quite a few networks that aren't 6to4 aware, hindering 
6to4 connectivity to non-6to4 addresses.


Jack

Re: Verizon outage between Baltimore and Washington

[Steven Fischer]

Technician on site, and excavation has begun.  Still no MTTR

On Wed, Nov 19, 2008 at 4:39 PM, Joel Esler <[EMAIL PROTECTED]> wrote:

> Just to agree, I am in Columbia, MD as well, and am unaffected.
>
> J
>
>
> On Nov 19, 2008, at 3:41 PM, Steven Fischer wrote:
>
>  looks like a single breakBaltimore is about 36.4 miles north of
>> Washington, and Laurel is about 16.25 miles north of Washington, with
>> Baltimore being about 20 miles north of Laurel.  All this makes sense.
>>  The
>> part that doesn't really make sense is that our headquarters in right
>> smack-dab along this run in Columbia, MD (about 5-7 miles north of
>> Laruel),
>> and has been unaffected...but a remote office in Hagerstown, about 50-60
>> miles west, north-west of here, is down hard.
>>
>
>


-- 
To him who is able to keep you from falling and to present you before his
glorious presence without fault and with great joy

Re: IPv6 routing /48s

[trejrco]

Yeah, that's part of why it isn't feasible :)

Also - a more generalized black-hole detection type mechanism (to also catch 
PMTUD failures, etc) would be mighty useful ... 


/TJ
--Original Message--
From: Nathan Ward
To: nanog list
Subject: Re: IPv6 routing /48s
Sent: Nov 19, 2008 15:34

On 20/11/2008, at 10:11 AM, [EMAIL PROTECTED] wrote:

> Ah yes, public-but-not-external IPv4 addresses ... I wish a stern  
> note saying don't do that was feasible ...


What people do with their addresses is their business.

The problem here is XPSP2/Vista assuming that non-RFC1918 = unfiltered/ 
unNATed for the purposes of 6to4.
Well, deeper problem is that they're using 6to4 on an end host I  
suppose - it's supposed to be used on routers.

I was going to write up a qualification mechanism for it so it could  
detect if 6to4 was OK or not, but code is already out there on umpteen  
million PCs that aren't going to do their patches.
I still plan to.. hopefully I'll get around to it when I feel a bit  
less jaded :-)

--
Nathan Ward







Sent from my Verizon Wireless BlackBerry

Re: Verizon outage between Baltimore and Washington

[Joel Esler]

Just to agree, I am in Columbia, MD as well, and am unaffected.

J

On Nov 19, 2008, at 3:41 PM, Steven Fischer wrote:


looks like a single breakBaltimore is about 36.4 miles north of
Washington, and Laurel is about 16.25 miles north of Washington, with
Baltimore being about 20 miles north of Laurel.  All this makes  
sense.  The

part that doesn't really make sense is that our headquarters in right
smack-dab along this run in Columbia, MD (about 5-7 miles north of  
Laruel),
and has been unaffected...but a remote office in Hagerstown, about  
50-60

miles west, north-west of here, is down hard.

Re: IPv6 routing /48s

[Nathan Ward]

On 20/11/2008, at 10:11 AM, [EMAIL PROTECTED] wrote:

Ah yes, public-but-not-external IPv4 addresses ... I wish a stern  
note saying don't do that was feasible ...



What people do with their addresses is their business.

The problem here is XPSP2/Vista assuming that non-RFC1918 = unfiltered/ 
unNATed for the purposes of 6to4.
Well, deeper problem is that they're using 6to4 on an end host I  
suppose - it's supposed to be used on routers.


I was going to write up a qualification mechanism for it so it could  
detect if 6to4 was OK or not, but code is already out there on umpteen  
million PCs that aren't going to do their patches.
I still plan to.. hopefully I'll get around to it when I feel a bit  
less jaded :-)


--
Nathan Ward

Re: Verizon outage between Baltimore and Washington

[Justin M. Streiner]

On Wed, 19 Nov 2008, Steven Fischer wrote:


  looks like a single breakBaltimore is about 36.4 miles north of
  Washington, and Laurel is about 16.25 miles north of Washington, with
  Baltimore being about 20 miles north of Laurel.  All this makes sense.  The
  part that doesn't really make sense is that our headquarters in right
  smack-dab along this run in Columbia, MD (about 5-7 miles north of Laruel),
  and has been unaffected...but a remote office in Hagerstown, about 50-60
  miles west, north-west of here, is down hard.


The circuit between you and your remote office could be DACS'd across several 
SONET rings between point A and B and if the cut took out one of those rings 
then you'd lose your circuit.  Also, keep in mind that carriers love to call 
SONET rings redundant even when both the working and protect sides of it ride 
in the same conduit, or hell, even in the same buffer.  That makes them a 
little more susceptible to backhoe fade.  There are other possibilities as 
well, such as the protect side of the ring being down for maintenance when 
something hits the working side, the carrier screws up a re-groom, etc...


jms

Re: IPv6 routing /48s

[trejrco]

Ah yes, public-but-not-external IPv4 addresses ... I wish a stern note saying 
don't do that was feasible ...

/TJ
--Original Message--
From: Nathan Ward
To: nanog list
Subject: Re: IPv6 routing /48s
Sent: Nov 19, 2008 15:02

On 20/11/2008, at 4:06 AM, Florian Weimer wrote:

> * Michael Sinatra:
>
>> And it just reinforces the fear that people have against putting 
>> records in DNS for their publicly-accessible resources, especially
>> www.
>
> Won't current Windows clients work just fine in this case?
>
> I have no idea what a fix should look like for some of the non-Windows
> systems I care about, unfortunately.


No, unfortunately broken 6to4 auto-configuration (ie, in Vista, XPSP2,  
when on a non-RFC1918 IP address) breaks, and you get 90s timeouts  
before falling back to IPv4/A.

Works fine most of the time, however when that non-RFC1918 address is  
behind NAT, or some sort of packet filter, then it doesn't work so  
well, and the client does not have a way to detect that reliably.

--
Nathan Ward







Sent from my Verizon Wireless BlackBerry

Re: IPv6 routing /48s

[Nathan Ward]

On 20/11/2008, at 4:06 AM, Florian Weimer wrote:


* Michael Sinatra:


And it just reinforces the fear that people have against putting 
records in DNS for their publicly-accessible resources, especially
www.


Won't current Windows clients work just fine in this case?

I have no idea what a fix should look like for some of the non-Windows
systems I care about, unfortunately.



No, unfortunately broken 6to4 auto-configuration (ie, in Vista, XPSP2,  
when on a non-RFC1918 IP address) breaks, and you get 90s timeouts  
before falling back to IPv4/A.


Works fine most of the time, however when that non-RFC1918 address is  
behind NAT, or some sort of packet filter, then it doesn't work so  
well, and the client does not have a way to detect that reliably.


--
Nathan Ward

Re: Verizon outage between Baltimore and Washington

[Steven Fischer]

looks like a single breakBaltimore is about 36.4 miles north of
Washington, and Laurel is about 16.25 miles north of Washington, with
Baltimore being about 20 miles north of Laurel.  All this makes sense.  The
part that doesn't really make sense is that our headquarters in right
smack-dab along this run in Columbia, MD (about 5-7 miles north of Laruel),
and has been unaffected...but a remote office in Hagerstown, about 50-60
miles west, north-west of here, is down hard.

On Wed, Nov 19, 2008 at 3:29 PM, <[EMAIL PROTECTED]> wrote:

> On Wed, 19 Nov 2008 14:53:48 EST, Steven Fischer said:
> > Can someone on the list shed some more light on this?  Verizon reports
> the 9
> > linear oc-48s are impacting 173 ds3s, 3 oc3cs, and 14 oc12cs. There is 1
> > unprotected oc192c down for TOT-A. OTDR readings from Baltimore place the
> > break at 36.4 miles towards Washington. Additional OTDR readings from
> Laurel
> > toward Washington indicate cut at 16.25 miles.
>
> Are the two OTDR readings consistent with one break on a shared segment
> of the DC-Balt and DC-Laurel runs, or is some cable-splicer having a
> *really*
> long day ahead?
>



-- 
To him who is able to keep you from falling and to present you before his
glorious presence without fault and with great joy

Re: Verizon outage between Baltimore and Washington

[Valdis . Kletnieks]

On Wed, 19 Nov 2008 14:53:48 EST, Steven Fischer said:
> Can someone on the list shed some more light on this?  Verizon reports the 9
> linear oc-48s are impacting 173 ds3s, 3 oc3cs, and 14 oc12cs. There is 1
> unprotected oc192c down for TOT-A. OTDR readings from Baltimore place the
> break at 36.4 miles towards Washington. Additional OTDR readings from Laurel
> toward Washington indicate cut at 16.25 miles.

Are the two OTDR readings consistent with one break on a shared segment
of the DC-Balt and DC-Laurel runs, or is some cable-splicer having a *really*
long day ahead?


pgpHIsrjGnPzw.pgp
Description: PGP signature

Verizon outage between Baltimore and Washington

[Steven Fischer]

Can someone on the list shed some more light on this?  Verizon reports the 9
linear oc-48s are impacting 173 ds3s, 3 oc3cs, and 14 oc12cs. There is 1
unprotected oc192c down for TOT-A. OTDR readings from Baltimore place the
break at 36.4 miles towards Washington. Additional OTDR readings from Laurel
toward Washington indicate cut at 16.25 miles.

Any additional info would be appreciated.

-- 
To him who is able to keep you from falling and to present you before his
glorious presence without fault and with great joy

Re: NAT66 and the subscriber prefix length

[Leo Vegoda]

On 19/11/2008 4:27, "Eugeniu Patrascu" <[EMAIL PROTECTED]> wrote:

[...]

> My gripe was that I wanted to get an IPv6 allocation from RIPE to start
> testing how IPv6 would fit in the company that I work for and build a
> dual stack network so that when the time comes, just switch on IPv6 BGP
> neighbors and update the DNS.
>
> But at almost 10.000 EUR per year it's an experiment I can't afford.

Where did the 10k come from? According the the 2009 billing scheme
(http://www.ripe.net/ripe/docs/ripe-437.html) the highest annual fee is
€5,500. The FAQ makes it clear that new members are automatically assigned
to the Extra Small billing category
(http://www.ripe.net/info/faq/membership/newlir-billing.html#2), putting
membership and the sign-up fee at €3,300.

I don't remember the RIPE NCC trying to sell expensive extras like a car
dealership. I'd be surprised if the prices quoted aren't the prices that
everyone pays.

Regards,

Leo

New Internet study released

[Irwin . Lazar]

Hi All,
Nemertes Research released a study on Internet Infrastructure this 
morning, this is an update to our 2007 study looking at Internet demand 
vs. growth of available bandwidth.  This year's update also includes an 
examination of routing/addressing trends, IPv6 adoption, and potential of 
other solutions such as LISP and application-based addressing.  It's 
freely available on our web site:

http://www.nemertes.com/internet_interrupted_why_architectural_limitations_will_fracture_net

thanks,
irwin

Adobe contact

[Jeff Calvert]

Hello,

Could someone from Adobe (AS1313) please contact me off list?  I'm having
some routing issues getting packets back from your network.

Thanks,

Jeff Calvert
[EMAIL PROTECTED]
[EMAIL PROTECTED]
713-821-1260 opt 2 (NOC)

Re: NAT66 and the subscriber prefix length

[Iljitsch van Beijnum]

On 14 nov 2008, at 14:55, Fred Baker wrote:

Before we get too deeply exercised, let Margaret and I huddle on it.  
The issue you raised can be trivially solved by adding the checksum  
offset to a different 16 bits in the address, such as bits 96..127.


Being checksum-equivalent is important so all protocols that use the  
standard checksum keep working without the NAT66 specifically  
supporting those protocols.


The trouble is that in one's complement math 0x is equivalent to  
0x which means that there is loss of information, so accommodating  
the difference in the lower bits means some nasty corner cases are  
possible, while if it's in the subnet bits you just lose one subnet.

RE: NAT66 and the subscriber prefix length

[michael.dillon]

> My gripe was that I wanted to get an IPv6 allocation from 
> RIPE to start 
> testing how IPv6 would fit in the company that I work for and build a 
> dual stack network so that when the time comes, just switch 
> on IPv6 BGP 
> neighbors and update the DNS.
> 
> But at almost 10.000 EUR per year it's an experiment I can't afford.

That is not an experiment.
An experiment is where you go to ,
generate your own unique RFC 4193 prefix, and then implement your IPv6
network using that. When you are ready to switch on BGP peering with the
rest of the world, get a /32 from your RIR, and renumber the network
leaving
the interface IDs the same.

If you are concerned that renumbering will be hard, go back and generate
another ULA, and renumber your network as part of your experiment. 

--Michael Dillon

Re: NAT66 and the subscriber prefix length

[Iljitsch van Beijnum]

On 19 nov 2008, at 9:27, Eugeniu Patrascu wrote:

My gripe was that I wanted to get an IPv6 allocation from RIPE to  
start testing how IPv6 would fit in the company that I work for and  
build a dual stack network so that when the time comes, just switch  
on IPv6 BGP neighbors and update the DNS.



But at almost 10.000 EUR per year it's an experiment I can't afford.


You don't need PI for most things. You certainly don't need it to  
experiment.

Re: NAT66 and the subscriber prefix length

[Eugeniu Patrascu]

Joe Abley wrote:

But surely he's not an end-user. He's an ISP, which means he's 
(potentially) an LIR.




My gripe was that I wanted to get an IPv6 allocation from RIPE to start 
testing how IPv6 would fit in the company that I work for and build a 
dual stack network so that when the time comes, just switch on IPv6 BGP 
neighbors and update the DNS.


But at almost 10.000 EUR per year it's an experiment I can't afford.

Re: IPv6 routing /48s

[Florian Weimer]

* Michael Sinatra:

> And it just reinforces the fear that people have against putting 
> records in DNS for their publicly-accessible resources, especially
> www.

Won't current Windows clients work just fine in this case?

I have no idea what a fix should look like for some of the non-Windows
systems I care about, unfortunately.

Re: NAT66 and the subscriber prefix length

[Joe Abley]

On 2008-11-19, at 09:25, Eugeniu Patrascu wrote:


[EMAIL PROTECTED] wrote:
We have also started offering residential Internet to those living  
on campus, which has been very popular (no suprise.)

You've started your own ISP. ISP's get a /32 from ARIN.
Case closed.
In fact, you are better off treating your non-ISP networks
as a customer of your ISP and assigning a /48 to each of
your non-ISP sites. This is an area where IPv4 and IPv6 differ.


Too bad in Europe RIPE wants 3000EUR per month membership fees to  
give you PI IPv6 if you're an end user.


But surely he's not an end-user. He's an ISP, which means he's  
(potentially) an LIR.



Joe

Re: NAT66 and the subscriber prefix length

[Eugeniu Patrascu]

[EMAIL PROTECTED] wrote:
We have also started offering residential Internet to those 
living on campus, which has been very popular (no suprise.) 


You've started your own ISP. ISP's get a /32 from ARIN.
Case closed.

In fact, you are better off treating your non-ISP networks
as a customer of your ISP and assigning a /48 to each of
your non-ISP sites. This is an area where IPv4 and IPv6 differ.


Too bad in Europe RIPE wants 3000EUR per month membership fees to give 
you PI IPv6 if you're an end user.

RE: NAT66 and the subscriber prefix length

[michael.dillon]

> We have also started offering residential Internet to those 
> living on campus, which has been very popular (no suprise.) 

You've started your own ISP. ISP's get a /32 from ARIN.
Case closed.

In fact, you are better off treating your non-ISP networks
as a customer of your ISP and assigning a /48 to each of
your non-ISP sites. This is an area where IPv4 and IPv6 differ.

--Michael Dillon