RE: It's Ars Tech's turn to bang the IPv4 exhaustion drum

[michael.dillon]

> I don't have a problem with assigning customers a /64 of v6 
> space.

Why so little? Normally customers get a /48 except for residential
customers who can be given a /56 if you want to keep track of
different block sizes. If ARIN will give you a /48 for every
customer, then why be miserly with addresses?

--Michael Dillon

RE: uTorrent, IPv6

[michael.dillon]

> So, if you run a network today, deploy 6to4 and Teredo 
> relays, regardless of whether you have customer facing IPv6 or not.
> If you serve IPv6 content, you are already running Teredo and 
> 6to4 relays, so that Windows Vista users get near to 
> IPv4-speed access to your IPv6 content, right? Right...

You can find info on how to set up relays at ARIN's IPv6 wiki


--Michael Dillon

Open Source CA / PKI

[Jon Kibler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

I am looking at deploying an open source CA/PKI for a client. It would
be only for internal users and systems. It would have to manage a few
hundred certificates against the organization's self-signed root cert.
It would be installed on a CentOS 5.x platform.

I have looked at OpenCA and Dogtag. Any other packages I should look at?

Does anyone have any opinions as to the pros and cons of either of these
packages or thoughts/comments/experience with other similar packages?

I would especially be interested in your experience with building /
installing the package and your opinion of the documentation available.

TIA for your help!

Jon Kibler
- --
Jon R. Kibler
Chief Technical Officer
Advanced Systems Engineering Technology, Inc.
Charleston, SC  USA
o: 843-849-8214
c: 843-224-2494
s: 843-564-4224

My PGP Fingerprint is:
BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiqkSQACgkQUVxQRc85QlPlGACgoAFitZXNLnEJfxKXgah00Vi8
dl4AniBPAJ3zy6krTKkFY3JQRdHAU6b9
=PGoy
-END PGP SIGNATURE-

Re: RouterOS performance?

[Robert E. Seastrom]

Joel Jaeggli <[EMAIL PROTECTED]> writes:

> I actually use freebsd as a router on soekris, but I do need a general
> purpose os on the system as well.

Speaking of Soekris (and the PCEngines ALIX by extension, of which I
have several):

Does anyone know of a comparable small SBC that doesn't have crummy
NICs?  Not a big fan of those VT6105M chips.  Extra points for the
ability to do baby jumbo frames.

Also, from time to time I have to reflash these to repurpose them
(NanoBSD vs. pfSense vs. AskoziaPBX).  It's a complete pain to
disassemble their enclosures so I can get at the CF cards.  I've often
thought that if someone had whipped up a memory-resident image of
something (anything, linux/bsd/whatever) that I could pxeboot, then I
could just dd the new image in over the net.  Haven't gotten around to
doing that yet.  Has anyone else?

-r

Re: RouterOS performance?

[Nathan Ward]

On 19/08/2008, at 11:32 PM, Robert E. Seastrom wrote:

Also, from time to time I have to reflash these to repurpose them
(NanoBSD vs. pfSense vs. AskoziaPBX).  It's a complete pain to
disassemble their enclosures so I can get at the CF cards.  I've often
thought that if someone had whipped up a memory-resident image of
something (anything, linux/bsd/whatever) that I could pxeboot, then I
could just dd the new image in over the net.  Haven't gotten around to
doing that yet.  Has anyone else?



My thing is memory resident, the kernel and root fs are all in one  
file. That's not exactly hard to do.
Not quite what you're looking for though, as config (including passwd  
etc.) isn't.

Wouldn't be difficult to change though.

Having said that, I strongly recommend getting your stuff to the point  
where it's a FAT formatted CF card, with a couple of files - 1 kernel,  
1 filesystem image. Filesystem images are good.
That way, you can mount your CF card somewhere, and 'reflash' from a  
live system. Just like, for example, a Cisco router. Upgrades are  
easy, just copy a new root FS+kernel on there.


--
Nathan Ward

Re: uTorrent, IPv6

[Laird Popkin]

My recollection is that there were complaints about them reconfiguring  
people's TCP stacks and uTorrent stopped enabling IPv6.


- Laird Popkin, CTO, Pando Networks
  http://www.pandonetworks.com
  520 Broadway, 10th Floor, NY, NY, 10012
  [EMAIL PROTECTED], 646/465-0570.

Sent from my iPhone. Apologies in advance for typo's.

On Aug 19, 2008, at 2:34 AM, Nathan Ward <[EMAIL PROTECTED]> wrote:


On 19/08/2008, at 6:28 PM, Mikael Abrahamsson wrote:


On Tue, 19 Aug 2008, Nathan Ward wrote:

uTorrent actively enables IPv6 on XP SP2 and Vista machines in the  
install process (by default, it can be turned off). IPv6 is turned  
on, on lots of PCs.


We looked into this, and IPv6 is not mentioned in the install  
process, and it's not selected by default as far as we can see.  
There is a button in Preferences->general that says "install IPv6/ 
Teredo", so yes, it supports it but it's not on by default, at  
least not here.


Oh? I looked in to this in a beta, and it was on by default.
I'll have another look.

--
Nathan Ward

RE: SLAAC(autoconfig) vs DHCPv6

[Darden, Patrick S.]

1.  I think ARP is effectively a ping for a mac.  It verifies connectivity on 
level 2 between two hosts.  You have to be on the same segment though

To make it work, you would have to know the mac address of the remote host, 
clear the  arp table the local host, then send the ARP request out.

This would still require that each host have IP stacks in place with 
functioning IP addresses.  Although ARP acts under IP, it still requires IP to 
function.

2.  I think you might be able to fudge it using RARP, if you just look for 
signals sent to that address. 

3.  A kind of constant ping might be... if you knew the remote's MAC address 
you could poison the ARP table with an announcement, spoof the MAC locally, 
then do MITM stuff and relay communications.

4.  Ok, after all that craziness I did a google search and found ARPING:  
http://en.wikipedia.org/wiki/Arping

ARPING still seems to rely upon a proper IP stack and address on both hosts.

Meh, your best bet might be just to scan your arp tables for the mac you are 
interested in.  I think all NICs broadcast periodically saying "I am here".  
Passive ping.
--p

-Original Message-
From: Howard C. Berkowitz [mailto:[EMAIL PROTECTED]
Sent: Monday, August 18, 2008 3:42 PM
To: nanog@nanog.org
Subject: RE: SLAAC(autoconfig) vs DHCPv6


This was especially a question when L2 was "in" and routing was out: how do
you ping a MAC address?

Re: RouterOS performance?

[Paul Vixie]

[EMAIL PROTECTED] ("Robert E. Seastrom") writes:

> Joel Jaeggli <[EMAIL PROTECTED]> writes:
>
>> I actually use freebsd as a router on soekris, but I do need a general
>> purpose os on the system as well.
>
> Speaking of Soekris (and the PCEngines ALIX by extension, of which I
> have several):
>
> Does anyone know of a comparable small SBC that doesn't have crummy
> NICs?  Not a big fan of those VT6105M chips.  Extra points for the
> ability to do baby jumbo frames.

http://www.plathome.com/products/microserver/obs/
-- 
Paul Vixie

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: RouterOS performance?

[Robert E. Seastrom]

Nathan Ward <[EMAIL PROTECTED]> writes:

> On 19/08/2008, at 11:32 PM, Robert E. Seastrom wrote:
>> Also, from time to time I have to reflash these to repurpose them
>> (NanoBSD vs. pfSense vs. AskoziaPBX).  It's a complete pain to
>> disassemble their enclosures so I can get at the CF cards.  I've often
>> thought that if someone had whipped up a memory-resident image of
>> something (anything, linux/bsd/whatever) that I could pxeboot, then I
>> could just dd the new image in over the net.  Haven't gotten around to
>> doing that yet.  Has anyone else?
>
> My thing is memory resident, the kernel and root fs are all in one
> file. That's not exactly hard to do.
> Not quite what you're looking for though, as config (including passwd
> etc.) isn't.
> Wouldn't be difficult to change though.
>
> Having said that, I strongly recommend getting your stuff to the point
> where it's a FAT formatted CF card, with a couple of files - 1 kernel,
> 1 filesystem image. Filesystem images are good.
> That way, you can mount your CF card somewhere, and 'reflash' from a
> live system. Just like, for example, a Cisco router. Upgrades are
> easy, just copy a new root FS+kernel on there.

I already have filesystem images (both from other people and of my own
manufacture).  I'm not sure I'm down with the fat32 cf card concept
though I can see where it could be useful.

What I want to do is have a minimal functionality netbootable image
that is sufficient to set up network interfaces and then do:

  ftp> get pfsense.img "| dd of=/dev/ad0"

and completely blow away what's on the flash and replace it with
something new (even via serial console over a networked console server
from my desk, without getting up and going to my lab where I have a
small herd of these puppies as packet pushers), but particularly
without having to break out a screwdriver and a nut driver and pull
four sheet metal screws, four machine screws, and two rs232 retaining
screw standoffs.

There is pxe in the bios on the ALIX... perhaps you know of something
that's already pxebootable that will do this?

---rob

Re: Is it time to abandon bogon prefix filters?

[Kevin Loch]

Jared Mauch wrote:


While you're at it, you also placed the reachable-via rx on
all your customer interfaces.  If you're paranoid, start with the 'any'
rpf and then move to the strict rpf.  The strict rpf also helps with
routing loops.


Be careful not to enable strict rpf on multihomed customers.  This includes
any bgp customer unless you know for sure they are single homed to you and that 
will not
change.

- Kevin

RE: It's Ars Tech's turn to bang the IPv4 exhaustion drum

[Justin M. Streiner]

On Tue, 19 Aug 2008, [EMAIL PROTECTED] wrote:


I don't have a problem with assigning customers a /64 of v6
space.


Why so little? Normally customers get a /48 except for residential
customers who can be given a /56 if you want to keep track of
different block sizes. If ARIN will give you a /48 for every
customer, then why be miserly with addresses?


I don't operate an ISP network (not anymore, anyway...).  My customers are 
departments within my organization, so a /64 per department/VLAN is more 
sane/reasonable for my environment.


jms

Re: RouterOS performance?

[Stefan Bethke]

Am 19.08.2008 um 16:28 schrieb Robert E. Seastrom:


What I want to do is have a minimal functionality netbootable image
that is sufficient to set up network interfaces and then do:

 ftp> get pfsense.img "| dd of=/dev/ad0"

and completely blow away what's on the flash and replace it with
something new[...]

There is pxe in the bios on the ALIX... perhaps you know of something
that's already pxebootable that will do this?


FreeBSD (or alike) will happily boot from PXE, either with NFS root or  
with an in-kernel RAM disk image.  Booting a kernel directly (instead  
of via loader(8)) is not officially supported anymore, but the last  
time I tried (around 6.2) it was still working.



Stefan

--
Stefan Bethke <[EMAIL PROTECTED]>   Fon +49 170 346 0140

Re: SLAAC(autoconfig) vs DHCPv6

[David W. Hankins]

On Mon, Aug 18, 2008 at 03:42:29PM -0400, Howard C. Berkowitz wrote:
> If you want to test a resource, be it the end user or an infrastructure
> interface, how do you know how to foo it (foo being some value of ping,
> traceroute, look it up in SNMP/NetFlow, etc)?
> 
> I submit that if you use dynamic assignment of any sort, you really have to
> have DNS dynamic update, so you can use a known name to query the function
> that's indexed by address.  Otherwise, static addresses become rather
> necessary if you want to check a resource. 

That's close.  If you use dynamic assignment via DHCP (v4 or v6),
then you have a handy database of all the IPv4 addresses assigned and
whatever information you want to discern them by (if not by hostname)
that was available to the DHCP server at the time of assignment.
Strictly speaking, Dynamic DNS isn't even necessary, but it could be
reasonably handy (because IPv6 addresses do not pass 'the phone
test').

With technologies like SLAAC, tho, you are right.  You're going to
have to give devices a means to register with the network
independently of their IP address allocation, because it only takes
one client to Router Solicit to configure multiple clients upon the
broadcast Router Advertisement reply.  Unless you start sniffing for
their neighbor discovery probes (part of SLAAC is to ensure the new
address is not already in use), there's no transaction where the
resource(s) are assigned.

There is quite obviously a key distribution problem with that kind of
model, and if you have to manually configure a system to configure
itself dynamically, there is a significantly diminished reward.

At this point in the excercise, you may as well do what the rest of us
in the current SLAAC-only world have done; disable SLAAC and set v6
addresses (and DNS) manually.  Welcome to 1985, the era DHCPv4 saved
us from.


But this leads you back to today's IPv6 operational problem; if you
need registered clients, then you can install any DHCPv6 software you
can find to get it via either its database or Dynamic DNS (quite a
lot of DHCPv6 server software supports Dynamic DNS).  But you still
wont' have any DHCPv6 clients outside of Vista.

This is where the chicken meets the egg on our faces.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?  https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins"If you don't do it right the first time,
Software Engineeryou'll just have to do it again."
Internet Systems Consortium, Inc.   -- Jack T. Hankins


pgplgk5oanCDo.pgp
Description: PGP signature

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum

[Michael Thomas]

Justin M. Streiner wrote:

On Tue, 19 Aug 2008, [EMAIL PROTECTED] wrote:


I don't have a problem with assigning customers a /64 of v6
space.


Why so little? Normally customers get a /48 except for residential
customers who can be given a /56 if you want to keep track of
different block sizes. If ARIN will give you a /48 for every
customer, then why be miserly with addresses?


I don't operate an ISP network (not anymore, anyway...).  My customers 
are departments within my organization, so a /64 per department/VLAN is 
more sane/reasonable for my environment.


Uh, the lower 64 bits of an IP6 address aren't used for routing you
know? They're essentially the mac address, or some other sort of
autoconf'd host identifier. Last I heard, the smallest allocation is
supposed to be a /48 -- I hadn't heard of the /56 thing that Michael
was speaking of, though I'm not surprised. There's 64 bits for
routing... no need to be so stingy :)

Mike

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum

[Randy Bush]

> Uh, the lower 64 bits of an IP6 address aren't used for routing


they are.  the /64 boundary is not in harwhere

randy

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum

[Nathan Ward]

On 20/08/2008, at 5:25 AM, Michael Thomas wrote:

Justin M. Streiner wrote:

On Tue, 19 Aug 2008, [EMAIL PROTECTED] wrote:

I don't have a problem with assigning customers a /64 of v6
space.


Why so little? Normally customers get a /48 except for residential
customers who can be given a /56 if you want to keep track of
different block sizes. If ARIN will give you a /48 for every
customer, then why be miserly with addresses?
I don't operate an ISP network (not anymore, anyway...).  My  
customers are departments within my organization, so a /64 per  
department/VLAN is more sane/reasonable for my environment.


Uh, the lower 64 bits of an IP6 address aren't used for routing you
know? They're essentially the mac address, or some other sort of
autoconf'd host identifier. Last I heard, the smallest allocation is
supposed to be a /48 -- I hadn't heard of the /56 thing that Michael
was speaking of, though I'm not surprised. There's 64 bits for
routing... no need to be so stingy :)



64 bits is not a magical boundary.

112 bits is widely recommended for linknets, for example.

64 bits is common, because of EUI-64 and friends. That's it.
There is nothing, anywhere, that says that the first 64 bits is for  
routing.


--
Nathan Ward

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum

[Seth Mattinen]

Michael Thomas wrote:
> Justin M. Streiner wrote:
>> On Tue, 19 Aug 2008, [EMAIL PROTECTED] wrote:
>>
 I don't have a problem with assigning customers a /64 of v6
 space.
>>>
>>> Why so little? Normally customers get a /48 except for residential
>>> customers who can be given a /56 if you want to keep track of
>>> different block sizes. If ARIN will give you a /48 for every
>>> customer, then why be miserly with addresses?
>>
>> I don't operate an ISP network (not anymore, anyway...).  My customers
>> are departments within my organization, so a /64 per department/VLAN
>> is more sane/reasonable for my environment.
> 
> Uh, the lower 64 bits of an IP6 address aren't used for routing you
> know? They're essentially the mac address, or some other sort of
> autoconf'd host identifier. Last I heard, the smallest allocation is
> supposed to be a /48 -- I hadn't heard of the /56 thing that Michael
> was speaking of, though I'm not surprised. There's 64 bits for
> routing... no need to be so stingy :)
> 

Last time I asked about this on the ipv6 list I got smacked for thinking
about using anything other than a /64 for subnets, even on point to
point links.

~Seth

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum

[Alain Durand]

On 8/19/08 1:36 PM, "Nathan Ward" <[EMAIL PROTECTED]> wrote:

> 64 bits is not a magical boundary.
> 
> 112 bits is widely recommended for linknets, for example.
> 
> 64 bits is common, because of EUI-64 and friends. That's it.
> There is nothing, anywhere, that says that the first 64 bits is for
> routing.


Actually, there is text that says so:
RFC4291: IPv6 Addressing Architecture, section 2.5.1

"  For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format."

The fact that most implementations ignore this is a different story.

In practice, many routers require the packet to go twice in the hardware if
the prefix length is > 64 bits, so even though it is a total waste of space,
it is not stupid to use /64 for point-to-point links and even for loopbacks!

  - Alain.

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum

[Randy Bush]

> In practice, many routers require the packet to go twice in the hardware if
> the prefix length is > 64 bits, so even though it is a total waste of space,
> it is not stupid to use /64 for point-to-point links and even for loopbacks!

some of us remember when we thought similarly for /24s for p2p links,
especially when using rip.

and consider matsuzaki-san's dos vulnerability on a /64 p2p link.  the
prudent operational advice today is to use a /127.

randy

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum

[Tony Finch]

On Tue, 19 Aug 2008, Michael Thomas wrote:
> Justin M. Streiner wrote:
> >
> > I don't operate an ISP network (not anymore, anyway...).  My customers
> > are departments within my organization, so a /64 per department/VLAN
> > is more sane/reasonable for my environment.
>
> Uh, the lower 64 bits of an IP6 address aren't used for routing you
> know? They're essentially the mac address, or some other sort of
> autoconf'd host identifier. Last I heard, the smallest allocation is
> supposed to be a /48 -- I hadn't heard of the /56 thing that Michael was
> speaking of, though I'm not surprised. There's 64 bits for routing... no
> need to be so stingy :)

It doesn't make sense to allocate a /48 to a (V)LAN. Address
autoconfiguration is based on the assumption that the only
reason for having more than one global /64 prefix on a LAN
is during renumbering.

Tony.
-- 
f.anthony.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
HEBRIDES BAILEY FAIR ISLE FAEROES: NORTH OR NORTHEAST 5 OR 6 DECREASING 4 OR
5, BECOMING VARIABLE 3 IN NORTH BAILEY AND WEST FAEROES LATER. MODERATE OR
ROUGH. MAINLY FAIR. MODERATE OR GOOD.

RE: It's Ars Tech's turn to bang the IPv4 exhaustion drum

[TJ]

>-Original Message-
>>> On Tue, 19 Aug 2008, [EMAIL PROTECTED] wrote:
> I don't have a problem with assigning customers a /64 of v6 space.

 Why so little? Normally customers get a /48 except for residential
 customers who can be given a /56 if you want to keep track of
 different block sizes. If ARIN will give you a /48 for every
 customer, then why be miserly with addresses?
>>> I don't operate an ISP network (not anymore, anyway...).  My
>>> customers are departments within my organization, so a /64 per
>>> department/VLAN is more sane/reasonable for my environment.
>>
>> Uh, the lower 64 bits of an IP6 address aren't used for routing you
>> know? They're essentially the mac address, or some other sort of
>> autoconf'd host identifier. Last I heard, the smallest allocation is
>> supposed to be a /48 -- I hadn't heard of the /56 thing that Michael
>> was speaking of, though I'm not surprised. There's 64 bits for
>> routing... no need to be so stingy :)
>
>
>64 bits is not a magical boundary.
>
>112 bits is widely recommended for linknets, for example.
>
>64 bits is common, because of EUI-64 and friends. That's it.
>There is nothing, anywhere, that says that the first 64 bits is for
routing.


Just to be clear - this http://tools.ietf.org/html/rfc4291#section-2.5.4
does say:
"   All Global Unicast addresses other than those that start with binary
   000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
   described in Section 2.5.1.  Global Unicast addresses that start with
   binary 000 have no such constraint on the size or structure of the
   interface ID field."

(And again - this is a case where the real world and the IETF may not agree
100% ...)


/TJ

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum

[Alain Durand]

On 8/19/08 1:50 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

>> In practice, many routers require the packet to go twice in the hardware if
>> the prefix length is > 64 bits, so even though it is a total waste of space,
>> it is not stupid to use /64 for point-to-point links and even for loopbacks!
> 
> Could you provide some documentation on this? First I've heard about it.

Ask your favorite router vendor. This has been confirmed to me by at least 3
major one we use.

 - Alain.

Re: uTorrent, IPv6

[Jay R. Ashworth]

On Tue, Aug 19, 2008 at 04:56:33PM +1200, Nathan Ward wrote:
> Sit up and pay attention, even if you don't now run IPv6, or even if
> you don't ever intend to run IPv6. Your off-net bandwidth is going to
> increase, unless you put some relays in. As a friend of mine just said
> to me: "Welcome to your v6-enabled transit network, whether you like
> it or not ;-)".

So you're saying Slashdot *lies*?

http://tech.slashdot.org/article.pl?sid=08/08/18/226228&from=rss
:-)

Cheers,
-- jra
-- 
Jay R. Ashworth[EMAIL PROTECTED]
Designer+-Internetworking--+-+RFC 2100
Ashworth & Associates   |  Best Practices Wiki | | '87 e24
St Petersburg FL USA+-http://bestpractices.wikia.com-+ +1 727 647 1274

  If you can read this... thank a system administrator.  Or two.  --me

OT: Again, sorry for the noise

[Joe Blanchard]

Hughes Net DNS issue. I am 72.169.156.122. Notice the Source is port 53,
destination is 20xx.
Because I am not a large company like McDonalds this apparently cannot be
resolved.

No. TimeSourceDestination   Protocol
Info
190 51.553317   72.169.156.12172.169.156.122DNS
Standard query response[Packet size limited during capture]

Frame 190 (122 bytes on wire, 96 bytes captured)
Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04
(00:d0:b7:a6:bb:04)
Internet Protocol, Src: 72.169.156.121 (72.169.156.121), Dst: 72.169.156.122
(72.169.156.122)
User Datagram Protocol, Src Port: domain (53), Dst Port: raid-sf (2014)
Domain Name System (response)
[Packet size limited during capture: DNS truncated]

No. TimeSourceDestination   Protocol
Info
191 51.553759   72.169.156.12272.169.156.121ICMP
Destination unreachable (Port unreachable)[Packet size limited during
capture]

Frame 191 (150 bytes on wire, 96 bytes captured)
Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a
(00:80:ae:b1:d4:3a)
Internet Protocol, Src: 72.169.156.122 (72.169.156.122), Dst: 72.169.156.121
(72.169.156.121)
Internet Control Message Protocol
[Packet size limited during capture: IP truncated]

No. TimeSourceDestination   Protocol
Info
192 51.643105   194.72.238.11 72.169.156.122DNS
Standard query response A 83.138.190.203

Frame 192 (96 bytes on wire, 96 bytes captured)
Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04
(00:d0:b7:a6:bb:04)
Internet Protocol, Src: 194.72.238.11 (194.72.238.11), Dst: 72.169.156.122
(72.169.156.122)
User Datagram Protocol, Src Port: domain (53), Dst Port: 11603 (11603)
Domain Name System (response)

No. TimeSourceDestination   Protocol
Info
193 51.648410   192.168.1.20  83.138.190.203TCP
vsat-control > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460

Frame 193 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a
(00:80:ae:b1:d4:3a)
Internet Protocol, Src: 192.168.1.20 (192.168.1.20), Dst: 83.138.190.203
(83.138.190.203)
Transmission Control Protocol, Src Port: vsat-control (1880), Dst Port: http
(80), Seq: 0, Len: 0

No. TimeSourceDestination   Protocol
Info
194 51.650140   83.138.190.20372.169.156.122TCP
http > 23230 [SYN, ACK] Seq=0 Ack=0 Win=8192 Len=0 MSS=1460

Frame 194 (64 bytes on wire, 64 bytes captured)
Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04
(00:d0:b7:a6:bb:04)
Internet Protocol, Src: 83.138.190.203 (83.138.190.203), Dst: 72.169.156.122
(72.169.156.122)
Transmission Control Protocol, Src Port: http (80), Dst Port: 23230 (23230),
Seq: 0, Ack: 0, Len: 0

No. TimeSourceDestination   Protocol
Info
195 51.650489   192.168.1.20  83.138.190.203TCP
vsat-control > http [ACK] Seq=1 Ack=1 Win=65535 Len=0

Frame 195 (54 bytes on wire, 54 bytes captured)
Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a
(00:80:ae:b1:d4:3a)
Internet Protocol, Src: 192.168.1.20 (192.168.1.20), Dst: 83.138.190.203
(83.138.190.203)
Transmission Control Protocol, Src Port: vsat-control (1880), Dst Port: http
(80), Seq: 1, Ack: 1, Len: 0

No. TimeSourceDestination   Protocol
Info
196 51.651024   192.168.1.20  83.138.190.203HTTP GET
/site_report?url=http://www.rocknyou.c [Packet size limited during capture]

Frame 196 (728 bytes on wire, 96 bytes captured)
Ethernet II, Src: Intel_a6:bb:04 (00:d0:b7:a6:bb:04), Dst: HughesNe_b1:d4:3a
(00:80:ae:b1:d4:3a)
Internet Protocol, Src: 192.168.1.20 (192.168.1.20), Dst: 83.138.190.203
(83.138.190.203)
Transmission Control Protocol, Src Port: vsat-control (1880), Dst Port: http
(80), Seq: 1, Ack: 1, Len: 674
Hypertext Transfer Protocol
[Packet size limited during capture: HTTP truncated]

No. TimeSourceDestination   Protocol
Info
197 51.753050   83.138.190.20372.169.156.122TCP
http > 23230 [ACK] Seq=1 Ack=674 Win=8192 Len=0

Frame 197 (64 bytes on wire, 64 bytes captured)
Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Dst: Intel_a6:bb:04
(00:d0:b7:a6:bb:04)
Internet Protocol, Src: 83.138.190.203 (83.138.190.203), Dst: 72.169.156.122
(72.169.156.122)
Transmission Control Protocol, Src Port: http (80), Dst Port: 23230 (23230),
Seq: 1, Ack: 674, Len: 0

No. TimeSourceDestination   Protocol
Info
198 51.882510   72.169.156.12172.169.156.122DNS
Standard query response[Packet size limited during capture]

Frame 198 (122 bytes on wire, 96 bytes captured)
Ethernet II, Src: HughesNe_b1:d4:3a (00:80:ae:b1:d4:3a), Ds

Re: uTorrent, IPv6

[Mikael Abrahamsson]

On Tue, 19 Aug 2008, Jay R. Ashworth wrote:


http://tech.slashdot.org/article.pl?sid=08/08/18/226228&from=rss


Well, IPv6 usage is actually increasing fairly rapidly, anyway:



So, still, usage is not very impressive (and some of that might be NNTP 
traffic), but slant of the yearly graph actually is.


--
Mikael Abrahamssonemail: [EMAIL PROTECTED]

Re: OT: Again, sorry for the noise

[Christopher Morrow]

On Tue, Aug 19, 2008 at 2:47 PM, Joe Blanchard <[EMAIL PROTECTED]> wrote:
> Hughes Net DNS issue. I am 72.169.156.122. Notice the Source is port 53,
> destination is 20xx.
> Because I am not a large company like McDonalds this apparently cannot be
> resolved.

wow that was a lot of really hard to read packet capture.. .maybe next
time just use tcpdump?? What exactly is the problem you are seeing and
one assumes you called your ISP for an attempted resolution? It seems
like your 122 host is spending a goodly amount of time making DNS
requests to .121, is .121 your default-gw + dns-server + dhcp-server ?
(and thus supposed to be getting this traffic?)

-Chris

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum

[Kevin Oberman]

> Date: Tue, 19 Aug 2008 14:30:38 -0400
> From: Alain Durand <[EMAIL PROTECTED]>
> 
> On 8/19/08 1:50 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> 
> >> In practice, many routers require the packet to go twice in the hardware if
> >> the prefix length is > 64 bits, so even though it is a total waste of 
> >> space,
> >> it is not stupid to use /64 for point-to-point links and even for 
> >> loopbacks!
> > 
> > Could you provide some documentation on this? First I've heard about it.
> 
> Ask your favorite router vendor. This has been confirmed to me by at least 3
> major one we use.

Odd. I have asked both of our router vendors and they have confirmed
that they route in the ASIC based on the full address, not just the
first 64 bits. (I believe one of them based on actual testing. I am
suspicious of the other.)

That said, one does use a few bits for something else (port) and does
not load them into the FIB, so I believe they route on 120 bits, not
128.

I'd love to get complete verification of the real facts of this.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751


pgp0952O4wGPG.pgp
Description: PGP signature

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum

[Kevin Loch]

Randy Bush wrote:

In practice, many routers require the packet to go twice in the hardware if
the prefix length is > 64 bits, so even though it is a total waste of space,
it is not stupid to use /64 for point-to-point links and even for loopbacks!


some of us remember when we thought similarly for /24s for p2p links,
especially when using rip.

and consider matsuzaki-san's dos vulnerability on a /64 p2p link.  the
prudent operational advice today is to use a /127.


I thought there was an issue with duplicate address detection with /127
(RFC3627)?  /126 should work and lots of folks use /112 which is a more
human-friendly bit boundary.  /112 is also good for multiple access
vlans and just about anything that isn't using autoconfig.

- Kevin

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum

[Alain Durand]

What I was told is that, yes, the packet get routed through the ASIC, but it
has to go there twice... Hence reducing the pps by a factor of 2 compare to
IPv4. Some vendors had shortcuts that, if the prefix len was < 64, only one
pass was necessary.

Caveat, this may not be true for all vendors or all models of all vendors.
YMMV.

  - Alain.


On 8/19/08 4:22 PM, "Kevin Oberman" <[EMAIL PROTECTED]> wrote:

>> Date: Tue, 19 Aug 2008 14:30:38 -0400
>> From: Alain Durand <[EMAIL PROTECTED]>
>> 
>> On 8/19/08 1:50 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>> 
 In practice, many routers require the packet to go twice in the hardware if
 the prefix length is > 64 bits, so even though it is a total waste of
 space,
 it is not stupid to use /64 for point-to-point links and even for
 loopbacks!
>>> 
>>> Could you provide some documentation on this? First I've heard about it.
>> 
>> Ask your favorite router vendor. This has been confirmed to me by at least 3
>> major one we use.
> 
> Odd. I have asked both of our router vendors and they have confirmed
> that they route in the ASIC based on the full address, not just the
> first 64 bits. (I believe one of them based on actual testing. I am
> suspicious of the other.)
> 
> That said, one does use a few bits for something else (port) and does
> not load them into the FIB, so I believe they route on 120 bits, not
> 128.
> 
> I'd love to get complete verification of the real facts of this.

RE: uTorrent, IPv6

[Mikael Lind]

We have seen the same growth curve on the Freenet6.net tunnelling service.
There hasn't been a peak in number of users so it seems people are just
using it more. Our link has actually been maxed out the last two months but
hopefully we will add more capacity soon and then we will see if the trend
continues. 

If anyone wants to help drive more IPv6 traffic and wants host a tunnel
gateway for Freenet6 please contact me off list. 

Mikael Lind

> 
> On Tue, 19 Aug 2008, Jay R. Ashworth wrote:
> 
> > http://tech.slashdot.org/article.pl?sid=08/08/18/226228&from=rss
> 
> Well, IPv6 usage is actually increasing fairly rapidly, anyway:
> 
> 
> 
> So, still, usage is not very impressive (and some of that might be NNTP
> traffic), but slant of the yearly graph actually is.
> 
> --
> Mikael Abrahamssonemail: [EMAIL PROTECTED]

Re: Smallest netblock that providers will accept?

[William Herrin]

On Tue, Aug 19, 2008 at 1:26 AM, Anton Kapela <[EMAIL PROTECTED]> wrote:
> The part that Kevin spares you from reading is the "please don't"
> part. [...] Instead of going down this road, I would suggest that you:
>
> -call up cisco and purchase a GSS (global dns lb with application
> availability probes, etc)

Anton,

By the time many folks consider redundant network links for
reliability they've already made design decisions which preclude this
path. My employer is in such a situation. They'd pay the $8k or so
annual systemic cost of a prefix if only there was someone they could
pay. But there isn't and even if we could afford the manpower to alter
our system to rely exclusively on DNS, our customers and the other
vendors involved have long since built systems that expect to
reference ours by IP address.


> -attach your site to a pair of willing upstreams who already have a
> larger prefix aggregate set aside (say a /18 or something) for
> end-site multihoming, in which it is expected that the prefix will be
> originated from disparate AS's (neither of which is the actual
> end-site).

Does someone offer such a service? Who?


Regards,
Bill Herrin


-- 
William D. Herrin  [EMAIL PROTECTED]  [EMAIL PROTECTED]
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum

[Randy Bush]

matsuzaki-san's preso, i think the copy he will present next week at apops:

   http://www.attn.jp/presentation/apnic26-maz-ipv6-p2p.pdf

randy

Re: uTorrent, IPv6

[Nathan Ward]

On 20/08/2008, at 6:39 AM, Jay R. Ashworth wrote:

On Tue, Aug 19, 2008 at 04:56:33PM +1200, Nathan Ward wrote:

Sit up and pay attention, even if you don't now run IPv6, or even if
you don't ever intend to run IPv6. Your off-net bandwidth is going to
increase, unless you put some relays in. As a friend of mine just  
said

to me: "Welcome to your v6-enabled transit network, whether you like
it or not ;-)".


So you're saying Slashdot *lies*?

http://tech.slashdot.org/article.pl?sid=08/08/18/226228&from=rss



They don't intentionally lie, but the study they are reporting on is  
uninformed.


For example:
"Our research looked at all IPv6 traffic—both native and tunneled,  
including Teredo, which encapsulates IPv4 traffic in UDP
datagrams using UDP port 3544. We found a peak of only 12 Mbps of  
Teredo traffic, representing around 10 percent of the

I P protocol 41 traffic."

Teredo uses 3544/UDP to for Client<->Server communication. That is for  
relay discovery when needed, and the qualification procedure - not  
much traffic. Client<->Relay communication MAY use 3544/UDP, Client<- 
>Client communication MAY use 3544/UDP.


In my experience (packets I have been analysing in the last 24 hours  
for example) suggests that not many actual data packets are on UDP/3544.

I'll get some exact numbers on that in a few hours if you like.


Also that report only includes data up until July 2008. uTorrent with  
Teredo and IPv6 stuff was released 9 August - which is the intention  
for my original message.


--
Nathan Ward

Re: uTorrent, IPv6

[Nathan Ward]

On 20/08/2008, at 6:57 AM, Mikael Abrahamsson wrote:


On Tue, 19 Aug 2008, Jay R. Ashworth wrote:


http://tech.slashdot.org/article.pl?sid=08/08/18/226228&from=rss


Well, IPv6 usage is actually increasing fairly rapidly, anyway:



So, still, usage is not very impressive (and some of that might be  
NNTP traffic), but slant of the yearly graph actually is.



Yep, and you're only seeing native data there.

Do you have any bead on how much of the IPv4 data is protocol 41 (I.e.  
IPv6 tunnelled over IPv4)?


I'm not going to ask you to find out how much of it is Teredo - that  
requires stateful DPI - but I expect it to be a non-insignificant  
number.



Those numbers can't be added together, because depending on a couple  
of factors (ie public relays and things), tunnelled traffic could be  
counted twice - once when encapsulated, once when native.


--
Nathan Ward

Re: Open Source CA / PKI

[Julien Goodwin]

On 19/08/08 19:23, Jon Kibler wrote:
> I am looking at deploying an open source CA/PKI for a client. It would
> be only for internal users and systems. It would have to manage a few
> hundred certificates against the organization's self-signed root cert.
> It would be installed on a CentOS 5.x platform.
> 
> I have looked at OpenCA and Dogtag. Any other packages I should look at?
I've used pyca on debian, however it needs a few scripts to better
automate bits of key management, unfortunately I didn't get those
released by my former employer (although I'm sure I could arrange it).

It's really lightweight and for the few dozen certs was easy for the
sysadmins to self-manage.

Re: Is it time to abandon bogon prefix filters?

[Pekka Savola]

On Tue, 19 Aug 2008, Kevin Loch wrote:

While you're at it, you also placed the reachable-via rx on
 all your customer interfaces.  If you're paranoid, start with the 'any'
 rpf and then move to the strict rpf.  The strict rpf also helps with
 routing loops.


Be careful not to enable strict rpf on multihomed customers.  This includes
any bgp customer unless you know for sure they are single homed to you and 
that will not

change.


Strict uRPF (feasible paths variant, RFC3704) works just fine with 
multihomed customers here.


But we don't allow TE more specifics either from the customer or from 
peers, so the longest prefix matching doesn't get messed up.  And with 
certain kind of p2p link numbering, you may need to add a dummy static 
route.  But it works.


For more see especially Section 3 of:
http://tools.ietf.org/id/draft-savola-bcp84-urpf-experiences-03.txt

(comments are also welcome.)

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings