On Thu, 22 Oct 2009 22:36:13 EDT, Jon Kibler said:
>4) Never allow traffic to ingress any network if the source address is
> bogus.
4a) Never flag a source address as bogus unless you can verify it is bogus
*today*, not when you installed the filter. Out of date bogon filters are evil.
p
Jon Kibler wrote:
> Zhiyun Qian wrote:
>> Hi all,
>
>> What is the common practice for enforcing port blocking policy (or what
>> is the common practice for you and your ISP)? More specifically, when
>> ISPs try to block certain outgoing port (port 25 for instance), they
>> could do two rules:
>>
> >> WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53?
> > You want to allow for more than one for obvious fault isolation and
> > load balancing reasons. The draft suggested using :::1
FWIW - I think simple anycast fits that bill.
> > I personally would suggest getting a well kno
On Oct 22, 2009, at 5:00 PM, Perry Lorier wrote:
trej...@gmail.com wrote:
WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53?
You want to allow for more than one for obvious fault isolation and
load balancing reasons. The draft suggested using :::1
I personally would suggest
On Oct 22, 2009, at 4:27 PM, Joe Maimon wrote:
Ray Soucy wrote:
Others may have their specific requests from vendors, but here are
mine:
1. Include DHCPv6 client functionality as part of any IPv6
implementation.
2. Support RA-gaurd and DHCPv6 snooping in L2 network infrastructure.
I
On Oct 22, 2009, at 4:14 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:
Few
companies use the MSP port (tcp/587).
Can you elaborate. Is this based on analysis you've conducted on
your own network? And if so, is the data (anonymized) available for
the rest of us to look at?
My experience is that
On Oct 22, 2009, at 4:12 PM, Karl Auer wrote:
On Thu, 2009-10-22 at 11:03 -0400, Kevin Loch wrote:
If, on the other hand, the REAL desire is to have a DHCP server
break
the tie in the selection between several routers that advertise
their
presence, that wouldn't be unreasonable.
In some
On Oct 22, 2009, at 3:39 PM, Justin Shore wrote:
Zhiyun Qian wrote:
Hi all,
What is the common practice for enforcing port blocking policy (or
what is the common practice for you and your ISP)? More
specifically, when ISPs try to block certain outgoing port (port 25
for instance), they c
Sean Donelan wrote:
> On Thu, 22 Oct 2009, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:
>> My experience is that port 587 isn't used because ISPs block it
>> out-of-hand. Or in the case of Rogers in (at least) Vancouver, hijack
>> it with a proxy that filters out the AUTH parts of the EHLO response,
>>
On Oct 22, 2009, at 2:31 PM, TJ wrote:
Then let me say it. RA needs to be able to be completely turned
off.
DHCPv6 needs to be able to completely configure all requesting hosts.
Those two statements are not synonymous ...
They may not be synonymous, but, there is a set of operators for
Joe Maimon wrote:
You can configure exchange to use additional smtp virtual servers and
bind them to specific ports. You can also require authentication to
access the ports and you can restrict it to users. You can also enable
it for STARTTLS.
That I did not know. Last time I'd looked there
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zhiyun Qian wrote:
> Hi all,
>
> What is the common practice for enforcing port blocking policy (or what
> is the common practice for you and your ISP)? More specifically, when
> ISPs try to block certain outgoing port (port 25 for instance), they
> c
On Thu, Oct 22, 2009 at 6:29 PM, Justin Shore wrote:
> I can also speak from experience from the enterprise customers of the
> consulting side of my SP that I worked with before returning to the SP. Not
> a one of them made use of the MSP port. The vast majority, I'm sorry to
> say, used Microso
Justin Shore wrote:
The vast majority, I'm
sorry to say, used Microsoft Exchange which to the best of my knowledge
doesn't support RFC2476.
You can configure exchange to use additional smtp virtual servers and
bind them to specific ports. You can also require authentication to
access th
Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:
Few
companies use the MSP port (tcp/587).
Can you elaborate. Is this based on analysis you've conducted on
your own network? And if so, is the data (anonymized) available for
the rest of us to look at?
My experience is that port 587 isn't used because IS
Sean Donelan wrote:
On Thu, 22 Oct 2009, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:
My experience is that port 587 isn't used because ISPs block it
out-of-hand. Or in the case of Rogers in (at least) Vancouver, hijack
it with a proxy that filters out the AUTH parts of the EHLO response,
making t
On Thu, 22 Oct 2009, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:
My experience is that port 587 isn't used because ISPs block it
out-of-hand. Or in the case of Rogers in (at least) Vancouver, hijack
it with a proxy that filters out the AUTH parts of the EHLO response,
making the whole point of using
trej...@gmail.com wrote:
WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53?
You want to allow for more than one for obvious fault isolation and load
balancing reasons. The draft suggested using :::1 I
personally would suggest getting a well known ULA-C allocation assigned
to
David W. Hankins wrote:
On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote:
Really. How do we deal with rouge DHCP on the wireless LAN, obviously
this is such a complex issue that we couldn't possibly have a solution
that could be applied to RA.
There are some wireless equipmen
On Fri, Oct 23, 2009 at 10:25:10AM +1100, Karl Auer wrote:
> I think it was really this that I was wanting more info on. "Entered"
> where?
On the address configured on the interface typically, or whatever
other system specifical local means are used to enter a route for the
prefix for the interfa
On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote:
> Really. How do we deal with rouge DHCP on the wireless LAN, obviously
> this is such a complex issue that we couldn't possibly have a solution
> that could be applied to RA.
There are some wireless equipment that claim to have a setting
Zhiyun Qian wrote:
1). For any outgoing traffic, if the destination port is 25, then drop
the packets.
2). For any incoming traffic, if the source port is 25, then drop the
packets.
It's been pointed that I glossed over the wording of #2, specifically
missing the "source port" part of it, thu
Ray Soucy wrote:
Others may have their specific requests from vendors, but here are mine:
1. Include DHCPv6 client functionality as part of any IPv6 implementation.
2. Support RA-gaurd and DHCPv6 snooping in L2 network infrastructure.
I can agree with that.
I would also add that there is
On Thu, 2009-10-22 at 16:16 -0700, David W. Hankins wrote:
> Unless of course it can fall back on native IPv4, or has entered a
> bogus covering /64.
I think it was really this that I was wanting more info on. "Entered"
where?
Sorry to be obtuse, clearly I am missing something obvious.
Regards,
Iljitsch van Beijnum wrote:
On 22 okt 2009, at 22:52, Mark Smith wrote:
Seriously, we're all adults. So treating us like children and
taking away the power tools is not appreciated.
Stop trying to break the internet and I'll treat you like an adult.
Great way to shoot down your own cr
On Thu, Oct 22, 2009 at 11:12:14AM +1100, Karl Auer wrote:
> > To work around this problem, some DHCPv6 software implementers have
> > elected to temporarily apply a fixed /64 bit prefix to all applied
> > addresses until a prefix length can be made available in-band through
> > some means. This d
> Few
> companies use the MSP port (tcp/587).
Can you elaborate. Is this based on analysis you've conducted on
your own network? And if so, is the data (anonymized) available for
the rest of us to look at?
My experience is that port 587 isn't used because ISPs block it
out-of-hand. Or in the ca
On Thu, 2009-10-22 at 11:03 -0400, Kevin Loch wrote:
> > If, on the other hand, the REAL desire is to have a DHCP server break
> > the tie in the selection between several routers that advertise their
> > presence, that wouldn't be unreasonable.
>
> In some configurations not all hosts are suppo
bmann...@vacation.karoshi.com wrote:
On Fri, Oct 23, 2009 at 12:22:52AM +1300, Perry Lorier wrote:
You could imagine extending this to other services such as NTP, but I'm
not sure that you really would want to go that far, perhaps using DNS to
lookup "_ntp._udp.local IN SRV" or similar to fi
Zhiyun Qian wrote:
Hi all,
What is the common practice for enforcing port blocking policy (or what
is the common practice for you and your ISP)? More specifically, when
ISPs try to block certain outgoing port (port 25 for instance), they
could do two rules:
1). For any outgoing traffic, if th
On 2009-10-22-16:19:53, Jeffrey Lyon wrote:
> Could a clueful AS1299 engineer please drop me a line? Dealing with
> the Level 0 technicians that are offered to IC clients is completely
> useless in diagnosing a rather serious issue.
r...@telia.net is a good place for routing/policy-related inquir
On Oct 22, 2009, at 4:32 PM, Ray Soucy wrote:
Knowing about it the
instant it happens might even be better than slowly coming to the
realization that you're dealing with one.
Might just be me, but I'm more worried about the rogue RA (or DHCPv4)
server that does not disrupt communication at
On 22 okt 2009, at 22:52, Mark Smith wrote:
Seriously, we're all adults. So treating us like children and
taking away the power tools is not appreciated.
Stop trying to break the internet and I'll treat you like an adult.
Great way to shoot down your own credibility. Just because you don
On Thu, 22 Oct 2009 13:22:17 -0400, Zhiyun Qian wrote:
1). For any outgoing traffic, if the destination port is 25, then drop
the packets.
2). For any incoming traffic, if the source port is 25, then drop the
packets.
Inspecting outgoing traffic is generally easier to do as there's less of
It's certainly encouraging to see how there is such consensus among
NANOG on IPv6 deployment. :-)
Recent exchanges seem to be getting a little personal, so we might
want to take a step back and breath.
I don't think adding default gateway support to DHCPv6 will have much
of an impact, but I'm OK
>
>
>>> Then let me say it. RA needs to be able to be completely turned off.
> DHCPv6 needs to be able to completely configure all requesting hosts.
Those two statements are not synonymous ...
Sure, leave RA in the IPv6 stack. The market will decide, and we will see if
> it is still on by defau
>
>
> Port based solutions don't work well on wireless networks and other
> mediums.
>
> Something like PSPF then? (assuming it works properly on IPv6 multicast ...
)
/TJ
Owen DeLong wrote:
Not at all. People are not saying RA has to go away. They are saying we
need the option of DHCPv6 doing the job where we do not feel that RA is
the correct tool.
Then let me say it. RA needs to be able to be completely turned off.
DHCPv6 needs to be able to completely
On Thu, 22 Oct 2009 11:40:50 +0200
Iljitsch van Beijnum wrote:
> On 21 okt 2009, at 22:48, Owen DeLong wrote:
>
> > The assumption that the router "knows" it is correct for every host
> > on a given
> > LAN simply does not map to reality deployed today.
>
> What I'm saying is that a router kn
Original Message
From: Ray Soucy
>Or is it that you want IPv6 to be a 128-bit version of IPv4?
Yes, this is in fact exactly what the network operators keep saying.
>RA is a
>good idea and it works. You can add options to DHCPv6, but I don't
>see many vendors implementing default
On Thu, 22 Oct 2009 21:20:11 +1100
Karl Auer wrote:
> On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote:
> > If, on the other hand, the REAL desire is to have a DHCP server break
> > the tie in the selection between several routers that advertise their
> > presence, that wouldn't
On Oct 22, 2009, at 12:23 PM, Ray Soucy wrote:
This to me is one of the least credible claims of the RA/SLAAC crowd.
On the one hand we have carriers around the world with millions and
millions of customers getting default routes and other config through
DHCPv4 every day. And most of the time i
On 22/10/09 16:06 -0400, Chuck Anderson wrote:
On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote:
Really. How do we deal with rouge DHCP on the wireless LAN, obviously
this is such a complex issue that we couldn't possibly have a solution
that could be applied to RA.
Rogue DHCP doesn'
Correct.
Not sure if you got the sarcasm in that last reply...
As far as I'm concerned, a rogue is a rogue. Knowing about it the
instant it happens might even be better than slowly coming to the
realization that you're dealing with one. The point is that we need
to address rogues regardless of
Tony,
On Oct 22, 2009, at 12:41 PM, Tony Hain wrote:
> The root of the argument I see in this entire thread is the assumption that
> 'what we have for IPv4 has *always* been there'.
Well, no. My reading is "what we have for IPv4 works, scales well, we're
accustomed to it, and our provisioning s
Could a clueful AS1299 engineer please drop me a line? Dealing with the
Level 0 technicians that are offered to IC clients is completely useless in
diagnosing a rather serious issue.
--
Jeffrey Lyon, Leadership Team
jeffrey.l...@blacklotus.net | http://www.blacklotus.net
Black Lotus Communication
On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote:
> Really. How do we deal with rouge DHCP on the wireless LAN, obviously
> this is such a complex issue that we couldn't possibly have a solution
> that could be applied to RA.
Rogue DHCP doesn't immedately take down the entire subnet of m
Really. How do we deal with rouge DHCP on the wireless LAN, obviously
this is such a complex issue that we couldn't possibly have a solution
that could be applied to RA.
On Thu, Oct 22, 2009 at 3:50 PM, Leo Bicknell wrote:
> In a message written on Thu, Oct 22, 2009 at 03:42:19PM -0400, Ray Souc
In a message written on Thu, Oct 22, 2009 at 03:42:19PM -0400, Ray Soucy wrote:
> The solution here, and one that is already being worked on by vendors,
> is RA gaurd, not changing DHCPv6 in an effort to bypass RA.
Port based solutions don't work well on wireless networks and other
mediums.
--
David Conrad wrote:
> > Ok, lets start with not breaking the functionality we have today
> > in IPv4. Once you get that working again we can look at new
> > ideas (like RA) that might have utility. Let the new stuff live/die
> on
> > it's own merits. The Internet is very good at sorting out the u
Sorry, not buying it.
The solution here, and one that is already being worked on by vendors,
is RA gaurd, not changing DHCPv6 in an effort to bypass RA.
What your proposing as a solution isn't much of a solution at all but
just a (seemingly) lesser problem.
On Thu, Oct 22, 2009 at 3:29 PM, Leo B
In a message written on Thu, Oct 22, 2009 at 03:23:13PM -0400, Ray Soucy wrote:
> If the argument against RA being used to provide gateway information
> is "rogue RA," then announcing gateway information though the use of
> DHCPv6 doesn't solve anything. Sure you'll get around rogue RA, but
> you'
> This to me is one of the least credible claims of the RA/SLAAC crowd.
> On the one hand we have carriers around the world with millions and
> millions of customers getting default routes and other config through
> DHCPv4 every day. And most of the time it actually works very well!
>
> On the othe
On Oct 22, 2009, at 3:03 PM, Vasil Kolev wrote:
В 11:10 -0700 на 22.10.2009 (чт), Owen DeLong написа:
OK... Here's the real requirement:
Systems administrators who do not control routers need the ability in
a dynamic host configuration mechanism to
assign a number of parameters to the hosts
В 11:10 -0700 на 22.10.2009 (чт), Owen DeLong написа:
> OK... Here's the real requirement:
>
> Systems administrators who do not control routers need the ability in
> a dynamic host configuration mechanism to
> assign a number of parameters to the hosts they administer through
> that dynamic
> > Like I said, if there's a bunch of routers announcing their presence
> > and you want a DHCP option to provide guidance to a host as to which
> > one to choose, that would be fine. But pointing to a potentially non-
> > existing address in the hopes that there will magically be a router
On Oct 22, 2009, at 8:44 AM, Iljitsch van Beijnum wrote:
On 22 okt 2009, at 17:03, Kevin Loch wrote:
If, on the other hand, the REAL desire is to have a DHCP server
break the tie in the selection between several routers that
advertise their presence, that wouldn't be unreasonable.
In so
On Thu, 22 Oct 2009 13:22:17 EDT, Zhiyun Qian said:
> Hi all,
>
> What is the common practice for enforcing port blocking policy (or
> what is the common practice for you and your ISP)? More specifically,
> when ISPs try to block certain outgoing port (port 25 for instance),
> they could do
On Thu, 22 Oct 2009, Zhiyun Qian wrote:
the common practice for you and your ISP)? More specifically, when ISPs try
to block certain outgoing port (port 25 for instance), they could do two
rules:
1). For any outgoing traffic, if the destination port is 25, then drop the
packets.
2). For any in
Hi all,
What is the common practice for enforcing port blocking policy (or
what is the common practice for you and your ISP)? More specifically,
when ISPs try to block certain outgoing port (port 25 for instance),
they could do two rules:
1). For any outgoing traffic, if the destination por
On Thu, Oct 22, 2009, Iljitsch van Beijnum wrote:
> What does that have to with anything? IPv6 stateless autoconfig
> predates the widespread use of DHCPv4.
So does IPX and IPX/RIP.
Why does this thread seem to rehash some big disconnect between
academics, IETF and actual deployment-oriented p
On 22 okt 2009, at 17:03, Kevin Loch wrote:
If, on the other hand, the REAL desire is to have a DHCP server
break the tie in the selection between several routers that
advertise their presence, that wouldn't be unreasonable.
In some configurations not all hosts are supposed to use the same
> Ok, lets start with not breaking the functionality we have today
> in IPv4. Once you get that working again we can look at new
> ideas (like RA) that might have utility. Let the new stuff live/die on
> it's own merits. The Internet is very good at sorting out the useful
> technology from the cr
Iljitsch van Beijnum wrote:
If, on the other hand, the REAL desire is to have a DHCP server break
the tie in the selection between several routers that advertise their
presence, that wouldn't be unreasonable.
In some configurations not all hosts are supposed to use the same
router. We need t
On Oct 22, 2009, at 8:14 AM, Alexander Harrowell wrote:
On Thursday 22 October 2009 12:38:11 Chris Edwards wrote:
On Thu, 22 Oct 2009, Alex Balashov wrote:
| Understood. I guess the angle I was going more for was: Is this
| actually practical to do in a country with almost as many
Internet
On 22/10/2009 12:49, bmann...@vacation.karoshi.com wrote:
its been a few weeks/years/minutes since I ran an exchange fabric,
but when we first turned up IPv6 - the first thing they did was try
to hand all the other routers IPv6 addresses. that pesky RA/ND
thing...
On Thu, 2009-10-22 at 14:25 +0200, Mohacsi Janos wrote:
> On Thu, 22 Oct 2009, bmann...@vacation.karoshi.com wrote:
> > I point you to a fairly common Internet architecture artifact,
> > the exchange point... dozens of routers sharing a common
> > media for peering exchange.
>
> And y
yes of course, sorry my wrong use of english.
Le jeudi 22 octobre 2009 à 05:19 -0700, Owen DeLong a écrit :
> Please don't break existing connectivity in an effort to show support
> for Hurricane.
>
> That's going in the wrong direction and it doesn't help the users of
> the internet, your
On Oct 22, 2009, at 7:38 AM, Chris Edwards wrote:
On Thu, 22 Oct 2009, Alex Balashov wrote:
| Understood. I guess the angle I was going more for was: Is this
actually
| practical to do in a country with almost as many Internet users as
the US has
| people?
|
| I had always assumed that
WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53?
... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve
FD00::/96 for this type of "ULA port-based anycast allocation". (16bits would
only reach w/o hex-conversion (if hex-converted could reserve FD00::/112
On Thu, 22 Oct 2009, bmann...@vacation.karoshi.com wrote:
On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote:
On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote:
If, on the other hand, the REAL desire is to have a DHCP server break
the tie in the selection between several
Please don't break existing connectivity in an effort to show support
for Hurricane.
That's going in the wrong direction and it doesn't help the users of
the internet, your customers,
or ours.
Please do continue to, or start peering with Hurricane.
The internet works best when people peer.
On Thursday 22 October 2009 12:38:11 Chris Edwards wrote:
> On Thu, 22 Oct 2009, Alex Balashov wrote:
> | Understood. I guess the angle I was going more for was: Is this
> | actually practical to do in a country with almost as many Internet users
> | as the US has people?
> |
> | I had always ass
Just to clear things up, I'm not advocating the use of 80-bit
prefixes. I was asking if they were a legitimate way to prevent SLAAC
in environments with hardware that don't support disabling the
autonomous flag for a prefix, or hosts that don't respect the
autonomous flag. I've since done some te
please full support huricane !
De-peer your ipv6 peering cogent/telia or max prepend it.
!
Le mercredi 21 octobre 2009 à 05:00 -0700, Matthew Petach a écrit :
> On Wed, Oct 21, 2009 at 12:13 AM, Richard A Steenbergen
> wrote:
>
> > On Tue, Oct 20, 2009 at 10:53:17PM -0700, Matthew Petach
On Thu, 2009-10-22 at 11:30 +, bmann...@vacation.karoshi.com wrote:
> > But my question was not about IPv6. How do IPv4 routers operate in such
> > a situation?
> exchange design 101.
Thanks :-)
I was being a bit Socratic. In the IPv4 world, routers in such complex
environments are gene
Interesting, curious... but meaningful?
To my mind Google's language seems to be focused on wireline issues,
which I guess are probably quite a bit easier for Verizon Wireless to
accommodate.
Conversely, VW's emphasis on continuing self-regulation of wireless
access would seem to be of seco
> > I point you to a fairly common Internet architecture artifact,
> > the exchange point... dozens of routers sharing a common
> > media for peering exchange.
>
> Bill, could you explain how or why ra or dhcp or dhcpv6 have any relevance
> to an IXP? Being one of these "artefact" o
On Oct 22, 2009, at 2:40 AM, Iljitsch van Beijnum wrote:
On 21 okt 2009, at 22:48, Owen DeLong wrote:
The assumption that the router "knows" it is correct for every host
on a given
LAN simply does not map to reality deployed today.
What I'm saying is that a router knows whether it's a rou
On Thu, Oct 22, 2009 at 12:35:18PM +0100, Nick Hilliard wrote:
> On 22/10/2009 11:30, bmann...@vacation.karoshi.com wrote:
> >On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote:
> >>The RA contains a preference level... maybe that doesn't cut it if
> >>multiple routers are sending the same p
On Fri, Oct 23, 2009 at 12:22:52AM +1300, Perry Lorier wrote:
>
> You could imagine extending this to other services such as NTP, but I'm
> not sure that you really would want to go that far, perhaps using DNS to
> lookup "_ntp._udp.local IN SRV" or similar to find your local NTP servers.
>
> A
On Thu, 22 Oct 2009, Alex Balashov wrote:
| Understood. I guess the angle I was going more for was: Is this actually
| practical to do in a country with almost as many Internet users as the US has
| people?
|
| I had always assumed that broad policies and ACLs work in China, but most
| forms of
On 22/10/2009 11:30, bmann...@vacation.karoshi.com wrote:
On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote:
The RA contains a preference level... maybe that doesn't cut it if
multiple routers are sending the same preference level, but presumably
that would not happen in a well-tended ne
On Thu, Oct 22, 2009 at 10:18:48PM +1100, Karl Auer wrote:
> On Thu, 2009-10-22 at 11:08 +, bmann...@vacation.karoshi.com wrote:
> > On Thu, Oct 22, 2009 at 09:44:38PM +1100, Karl Auer wrote:
> > > On Thu, 2009-10-22 at 10:30 +, bmann...@vacation.karoshi.com wrote:
> > > > > The RA contains
Lots of good info, and a nice mind-dump that gives me a whole host of other
things that need to be looked at... Umm. "thanks" :)
On Wed, Oct 21, 2009 at 11:10 PM, Perry Lorier wrote:
> Rick Ernst wrote:
>
>> Resent, since I responded from the wrong address:
>> ---
>> The basic operation of IP SL
bmann...@vacation.karoshi.com wrote:
On Thu, Oct 22, 2009 at 12:02:14PM +0200, Iljitsch van Beijnum wrote:
On 22 okt 2009, at 01:55, bmann...@vacation.karoshi.com wrote:
so your not a fan of the smart edge and the stupid network.
I'm a fan of getting things right. A serv
On Thu, 2009-10-22 at 11:08 +, bmann...@vacation.karoshi.com wrote:
> On Thu, Oct 22, 2009 at 09:44:38PM +1100, Karl Auer wrote:
> > On Thu, 2009-10-22 at 10:30 +, bmann...@vacation.karoshi.com wrote:
> > > > The RA contains a preference level... maybe that doesn't cut it if
> > >
> > >
On Thu, Oct 22, 2009 at 09:44:38PM +1100, Karl Auer wrote:
> On Thu, 2009-10-22 at 10:30 +, bmann...@vacation.karoshi.com wrote:
> > > The RA contains a preference level... maybe that doesn't cut it if
> > > multiple routers are sending the same preference level, but presumably
> > > that would
On Oct 21, 2009, at 11:03 PM, Rick Ernst wrote:
I thought that would keep the clocks more closely in sync. I don't
necessarily care if the time is 'right', just that it's the same.
ntp is a pretty basic operational requirement for any network,
irrespective of the use of IP SLA, is it not
On Thu, 2009-10-22 at 10:30 +, bmann...@vacation.karoshi.com wrote:
> > The RA contains a preference level... maybe that doesn't cut it if
> > multiple routers are sending the same preference level, but presumably
> > that would not happen in a well-tended network.
>
> I point you to a f
On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote:
> On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote:
> > If, on the other hand, the REAL desire is to have a DHCP server break
> > the tie in the selection between several routers that advertise their
> > presence, that woul
On Thu, Oct 22, 2009 at 12:02:14PM +0200, Iljitsch van Beijnum wrote:
> On 22 okt 2009, at 01:55, bmann...@vacation.karoshi.com wrote:
>
> > so your not a fan of the smart edge and the stupid network.
>
> I'm a fan of getting things right. A server somewhere 5 subnets away
> doesn't really
On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote:
> If, on the other hand, the REAL desire is to have a DHCP server break
> the tie in the selection between several routers that advertise their
> presence, that wouldn't be unreasonable.
The RA contains a preference level... maybe
On 22 okt 2009, at 01:55, bmann...@vacation.karoshi.com wrote:
so your not a fan of the smart edge and the stupid network.
I'm a fan of getting things right. A server somewhere 5 subnets away
doesn't really know what routers are working on my subnet. It can take
a guess and then wa
On 21 okt 2009, at 23:34, David W. Hankins wrote:
There is a problem with the "Both RA and DHCPv6 Model" currently
proposed by IETF iconoclasts. Should RA fail, for any reason from
router, system, software, network path, security, or user error,
then the simplest networks imaginable (where host
On 21 okt 2009, at 22:48, Owen DeLong wrote:
The assumption that the router "knows" it is correct for every host
on a given
LAN simply does not map to reality deployed today.
What I'm saying is that a router knows whether it's a router or not. A
DHCP server does not, so it has to make a le
Chris Edwards wrote:
Doesn't necessarily have to be hugely accurate. The authorities could
simply identify a few likely suspect tunnels, then knock-on-doors and ask
you to explain what the traffic in question is...
Understood. I guess the angle I was going more for was: Is this
actually p
On Wed, 21 Oct 2009, Alex Balashov wrote:
| I was not aware that tools or techniques to do this are widespread or highly
| functional in a way that would get them adopted in an Internet access control
| application of a national scope.
Doesn't necessarily have to be hugely accurate. The authorit
Adrian Chadd writes:
> On Wed, Oct 21, 2009, Alex Balashov wrote:
> > I was not aware that tools or techniques to do this are widespread or
> > highly functional in a way that would get them adopted in an Internet
> > access control application of a national scope.
> >
> > Tell me more?
>
>
99 matches
Mail list logo
