Re: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)

[Martin Hannigan]

On 9/15/07, Jeroen Massar <[EMAIL PROTECTED]> wrote:
> [spam: Check http://www.sixxs.net/misc/toys/ for an IPv6 Toy Gallery :)]
>
> Somewhat long, hopefully useful content follows...
>
> Barrett Lyon wrote:
> [..]

[ clip ]

> Of course when there is only a A or  only that protocol will be
> used. All applications are supposed to use getaddrinfo() which sorts
> these addresses per the above specification, the app should then
> connect() to them in order, fail/timeout and try the next one till it

Since when is a timeout on the Internet ok? Haven't we moved beyond
that? This is a controllable timeout. We don't have to do it, which is
the point. What's the right way to do this?

Thank you, and thank you Barret for starting the thread. :-)

-M<

RE: Question on Loosely Synchronized Router Clocks

[Buhrmaster, Gary]

> Kerberos does not assume clock synchronization.
> Kerberos requires reasonable clock synchronization.

To be more precise, Kerberos requires those systems
for which it is providing (authentication) services
to agree, within a configured (usually) 5-10 minutes.
There is no requirement that those systems have to
agree with anything else outside of their realm.  
If a particular set of servers all agree that it is
currently Jan 10th, 1980, at 0913, Kerberos can be
fine with that.

Of course, usually, NTP (or something like that) is
used to keep all the servers "near" UTC, but keeping
clocks at UTC is not a Kerberos requirement.

> And, as near as I can tell, clock synchronization is not part 
> of the Kerberos protocol.

It is not, but note that some localized distributions
of Kerberos clients did, indeed, ship with various time
synchronization tools before they were common on
platforms such as Windows and Mac, so some users may
have thought that installing Kerberos meant they got
clock synchronization.

Re: Question on Loosely Synchronized Router Clocks

[Steven M. Bellovin]

On Thu, 20 Sep 2007 14:41:16 -0500
"Brandon Galbraith" <[EMAIL PROTECTED]> wrote:

> On 9/20/07, James R. Cutler <[EMAIL PROTECTED]> wrote:
> >
> >  Kerberos does not assume clock synchronization.
> > Kerberos requires reasonable clock synchronization.
> > And, as near as I can tell, clock synchronization is not part of the
> > Kerberos protocol.
> >
> > Kick me if I err in this.
> >
> > Cutler
> >
> 
> http://en.wikipedia.org/wiki/Kerberos_%28protocol%29#Kerberos_drawbacks
> 
> "Kerberos requires the clocks of the involved hosts to be
> synchronized. The tickets have time availability period and, if the
> host clock is not synchronized with the clock of Kerberos server, the
> authentication will fail. The default configuration requires that
> clock times are no more than 10 minutes apart. In practice,
> NTPdaemons are
> usually employed to keep the host clocks synchronized."

That's correct, though I believe some versions use an offset hack.

The initial exchange with the Kerberos server is strongly
authenticated.  It's used to issue a ticket-granting ticket; replay of
TGTs (and service tickets obtained via TGTs) partially relies on
synchronized clocks.  The offset hack has the Kerberos server -- a
universally trusted party -- note and seal in the tickets -- the
client's time offset from KDC reality.  Any services that accept the
tickets can use this value to correct for clock skew.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

Re: Question on Loosely Synchronized Router Clocks

[Brandon Galbraith]

On 9/20/07, James R. Cutler <[EMAIL PROTECTED]> wrote:
>
>  Kerberos does not assume clock synchronization.
> Kerberos requires reasonable clock synchronization.
> And, as near as I can tell, clock synchronization is not part of the
> Kerberos protocol.
>
> Kick me if I err in this.
>
> Cutler
>

http://en.wikipedia.org/wiki/Kerberos_%28protocol%29#Kerberos_drawbacks

"Kerberos requires the clocks of the involved hosts to be synchronized. The
tickets have time availability period and, if the host clock is not
synchronized with the clock of Kerberos server, the authentication will
fail. The default configuration requires that clock times are no more than
10 minutes apart. In practice,
NTPdaemons are
usually employed to keep the host clocks synchronized."

Re: Question on Loosely Synchronized Router Clocks

[James R. Cutler]

Kerberos does not assume clock synchronization.
Kerberos requires reasonable clock synchronization.
And, as near as I can tell, clock synchronization is not part of the 
Kerberos protocol.


Kick me if I err in this.

Cutler

At 9/19/2007 08:14 AM -0400, Jeff McAdams wrote:
Stephen Sprunk wrote:
>> ... is it reasonable to assume clock synchronization in the rest
>> of our design?

> In general, it is not.  I can't think of any existing protocol that
> does, actually.

Kerberos.
--
Jeff McAdams
"They that can give up essential liberty to obtain a
little temporary safety deserve neither liberty nor safety."
   -- Benjamin Franklin




-
James R. Cutler
[EMAIL PROTECTED]

Re: ticket research

[Marshall Eubanks]

Dear Randy;

On Sep 20, 2007, at 11:44 AM, Randy Bush wrote:



a respected researcher (with a grad student) i trust wants to


obtain trouble ticket logs from different networks to understand the
nature of failures in ISP networks. we hope that this analysis will
help us develop troubleshooting techniques.


they have some data already from abiline and a large euro telco.  
further,



we can sign NDAs if needed and we'll anonymize the data before
publishing.


they realize that such data are extremely sensitive.  and also know  
that

they are buried in kinky databases etc.  but one has to try.



Do they want tickets from ISP's or from users ? (Or, more precisely,  
from people experiencing

problems, or those fixing them ?)

Regards
Marshall

( and let's try not to rat-hole on nanog about why this is good,  
insane,

will cause starvation in iowa, might end global warming, ... :)

if you think you might be willing to help, drop me a note and i will
introduce you.  thanks.

randy

ticket research

[Randy Bush]

a respected researcher (with a grad student) i trust wants to

> obtain trouble ticket logs from different networks to understand the 
> nature of failures in ISP networks. we hope that this analysis will 
> help us develop troubleshooting techniques.

they have some data already from abiline and a large euro telco. further,

> we can sign NDAs if needed and we'll anonymize the data before
> publishing.

they realize that such data are extremely sensitive.  and also know that
they are buried in kinky databases etc.  but one has to try.

( and let's try not to rat-hole on nanog about why this is good, insane,
will cause starvation in iowa, might end global warming, ... :)

if you think you might be willing to help, drop me a note and i will
introduce you.  thanks.

randy

RE: Level 3 in Ohio

[Mike Callahan]

Level3 was experiencing problems with their own 8xx number yesterday.

Start Date/Time: 9/19/2007 17:30 GMT
End Date/Time: Ongoing

Summary: Level 3 Communications is currently investigating issues with 
calls to our Toll Free 8774538353. If you are attempting to call 
8774538353 and get fast busy please send e-mail to [EMAIL PROTECTED]  A 
detailed update will shortly follow informing you of the results of the 
investigation.

Mike


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Marshall Eubanks
Sent: Wednesday, September 19, 2007 1:34 PM
To: nanog list
Subject: Level 3 in Ohio



Is anyone reporting Level3 outages in Ohio or DC ?

One of my clients is down, and L3 is not answering the phones (!)

traceroute 65.89.42.1

(From Cogent in Tyson's Corner)

traceroute to 65.89.42.1 (65.89.42.1), 30 hops max, 38 byte packets
1  dmz-mct2.multicasttech.com (63.105.122.1)  0.367 ms  0.265 ms   
0.238 ms
2  g0-7.na21.b002176-1.dca01.atlas.cogentco.com (38.99.206.153)   
0.598 ms  0.548 ms  0.529 ms
3  g2-1-3587.core01.dca01.atlas.cogentco.com (38.20.32.13)  0.862 ms   
0.834 ms  0.740 ms
4  t4-1.mpd01.dca01.atlas.cogentco.com (154.54.3.158)  0.801 ms   
0.879 ms *
5  v3493.mpd01.dca02.atlas.cogentco.com (154.54.7.2)  1.328 ms  1.311  
ms  1.247 ms
6  t1-4.mpd01.iad01.atlas.cogentco.com (154.54.7.162)  1.693 ms   
1.598 ms  1.605 ms
7  g4-0-3490.core01.iad01.atlas.cogentco.com (154.54.3.225)  1.411  
ms  1.453 ms  1.552 ms
8  oc48-6-0-2.edge2.Washington3.Level3.net (4.68.127.9)  1.577 ms   
1.588 ms  16.498 ms
9  ae-44-99.car4.Washington1.Level3.net (4.68.17.198)  2.766 ms  
ae-24-79.car4.Washington1.Level3.net (4.68.17.70)  3.282 ms  
ae-34-89.car4.Washington1.Level3.net (4.68.17.134)  2.808 ms


Cox Cable in Northern Virginia
[TME-Laptop-2:~/Movies/NoisiVision] tme% traceroute 65.89.42.1
traceroute to 65.89.42.1 (65.89.42.1), 64 hops max, 40 byte packets
1  * * *
2  ip70-179-104-1.dc.dc.cox.net (70.179.104.1)  14.989 ms  11.563 ms   
11.782 ms
3  ip68-100-1-161.dc.dc.cox.net (68.100.1.161)  18.078 ms  12.329 ms   
12.036 ms
4  ip68-100-0-1.dc.dc.cox.net (68.100.0.1)  13.368 ms  12.301 ms   
11.960 ms
5  mrfddsrj01-ge110.rd.dc.cox.net (68.100.0.161)  12.504 ms  11.729 ms *
6  xe-9-2-0.edge1.washington1.level3.net (4.79.228.61)  59.189 ms   
12.721 ms  11.749 ms
7  ae-44-99.car4.washington1.level3.net (4.68.17.198)  13.502 ms   
13.389 ms ae-34-89.car4.washington1.level3.net (4.68.17.134)  14.290 ms


(Note that both trace routes appear to be flapping at the last  
reported hop.

Regards
Marshall

RE: ipv6/v4 naming nomenclature [Was: Apple Air...]

[michael.dillon]

> >> Don't come up with any other variants. The above form is 
> what is in 
> >> general use around the internet and what some people will at least 
> >> try to use in cases where a DNS label has both an  and 
> A and one 
> >> of them doesn't work. 

> Where did the www.ipv6 and www.ipv4 "standard" come from?

He already explained that as quoted above. It is a de-facto
standard since that is what is in general use around the
Internet. Standards are not always created by standards groups,
sometimes they just grows, like Topsy.

The key thing here is that adding  records for a host that also
has an A record, can cause strange things to happen. If this would 
be bad for the services offered by the host with the A record, then
you can create two new pseudo-hosts ipv6.host and ipv4.host. Put the
 record only on the ipv6.host entry, and make the ipv4.host entry
either a duplicate of, or a CNAME to the original host with the A
record.

That way, you can still get some IPv6 traffic from IPv6 knowledgeable 
people for testing purposes. Or you can solicit people to help with
your testing by using the ipv6.host variant.

--Michael Dillon

RE: Going dual-stack, how do apps behave and what to do as an operator (Was: Apple Airport Extreme IPv6 problems?)

[michael.dillon]

> > If there's interest I'll hack up a FreeBSD nanobsd image with ipv6 
> > support, a routing daemon (whatever people think is good 
> enough) and 
> > whatever other stuff is "enough" to act as a 6to4 gateway.
> > You too can build diskless core2duo software routers for USD $1k.
> 
> What about Soekris hardware? I don't have any personal 
> experience with it, but it looks very appealing to build load 
> balancers/routers out of, and quite inexpensive.

Before you choose which hardware platform to use, you should take
a look at the software platform and see what other people are using.
There are dozens of Linux router distros like OpenWRT out there.

http://leaf.sourceforge.net/  Linux Embedded gateway/router/firewall

http://www.linuxdevices.com/articles/AT6003080606.html Building a low
cost router appliance

Linux Devices is a good site to find information about embedded
hardware platforms that support Linux. There are a lot of possibilities
ranging from fanless x86 systems built around a Via EPIA motherboard
to traditional embedded platforms based around ARM or MIPS processors.

And just about anything that runs Linux will also run BSD if that is
what you want.

--Michael Dillon