Vasil Kolev va...@ludost.net, 2009-10-22 21:03 (+0200):
how should we provide DNS and other useful information for the V6 only
people?
What Router Advertisment server did you use? The radvd server supports
RFC 5006, an extension to vanilla RA that gives an address to a
resolving DNS server
The Wi-Fi MAC protocol has a pair of header bits that mean from AP
and to AP. In ad-hoc mode, a designated station acts as an AP, so
that's nothing special. There are a couple of non-AP modes for direct
link exchanges and peer-to-peer exchances that probably don't set from
AP but
Adrian Chadd adr...@creative.net.au wrote:
As already said, wireless in infrastructure mode (with access points)
always sends traffic between clients through the access point, so a
decent AP can filter this.
How does the client determine that the traffic came from the AP versus
another
And of course, a rogue RA station would _NEVER_ mess with that bit
in what it transmits...
Uh, yeah.
Owen
On Nov 7, 2009, at 2:41 AM, Richard Bennett wrote:
The Wi-Fi MAC protocol has a pair of header bits that mean from AP
and to AP. In ad-hoc mode, a designated station acts as an AP,
It's not all that easy unless the dude has hacked the device driver.
Owen DeLong wrote:
And of course, a rogue RA station would _NEVER_ mess with that bit
in what it transmits...
Uh, yeah.
Owen
On Nov 7, 2009, at 2:41 AM, Richard Bennett wrote:
The Wi-Fi MAC protocol has a pair of header
: Bernhard Schmidt; nanog@nanog.org
Subject: Re: {SPAM?} Re: IPv6 Deployment for the LAN
It's not all that easy unless the dude has hacked the device driver.
Owen DeLong wrote:
And of course, a rogue RA station would _NEVER_ mess with that bit
in what it transmits...
Uh, yeah.
Owen
On Nov 7
On Thu, 29 Oct 2009 08:40:46 +0900
Randy Bush ra...@psg.com wrote:
This would be a big mistake. Fate sharing between the device that
advertises the presence of a router and the device that forwards
packets makes RAs much more robust than DHCPv4.
No, what we want are better first hop
Iljitsch van Beijnum wrote:
This would be a big mistake. Fate sharing between the device that
advertises the presence of a router and the device that forwards packets
makes RAs much more robust than DHCPv4.
No, what we want are better first hop redundancy protocols, and DHCP for
v6, so that
This would be a big mistake. Fate sharing between the device that
advertises the presence of a router and the device that forwards packets
makes RAs much more robust than DHCPv4.
No, what we want are better first hop redundancy protocols, and DHCP for
v6, so that everyone who has extracted
Amen to that Randy.
MMC
Randy Bush wrote:
This would be a big mistake. Fate sharing between the device that
advertises the presence of a router and the device that forwards packets
makes RAs much more robust than DHCPv4.
No, what we want are better first hop redundancy protocols, and
This is unusual, but, I have to agree with Randy here.
Owen
On Oct 28, 2009, at 5:09 PM, Matthew Moyle-Croft wrote:
Amen to that Randy.
MMC
Randy Bush wrote:
This would be a big mistake. Fate sharing between the device that
advertises the presence of a router and the device that forwards
On Sat, Oct 24, 2009 at 11:33 PM, Karl Auer ka...@biplane.com.au wrote:
On Fri, 2009-10-23 at 20:48 -0700, Joel Jaeggli wrote:
the mac address of the rouge server
pedantic
It's R-O-G-U-E - rogue.
Rouge is French for red and English for red make-up.
Also the name of the Ford assembly plant
On wireless networks you can note the mac address of the rouge server
and dissociate it from the wireless network, this is rather similar to
what we did on switches prior to dhcp protection, it is reactive but it
certainly can be automatic.
Some controller based wireless systems have ips or nac
On Fri, 2009-10-23 at 20:48 -0700, Joel Jaeggli wrote:
the mac address of the rouge server
pedantic
It's R-O-G-U-E - rogue.
Rouge is French for red and English for red make-up.
/pedantic
Regards, K.
--
~~~
Karl Auer
On Sun, 25 Oct 2009 17:33:34 +1100
Karl Auer ka...@biplane.com.au wrote:
On Fri, 2009-10-23 at 20:48 -0700, Joel Jaeggli wrote:
the mac address of the rouge server
pedantic
It's R-O-G-U-E - rogue.
Rouge is French for red and English for red make-up.
/pedantic
Also the colour of
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 prefix:::1 I
personally would suggest getting a well known ULA-C allocation
assigned to IANA, then use
TJ 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 prefix:::1
FWIW - I think simple anycast fits that bill.
I think for very
WRT Anycast DNS; Perhaps a special-case of ULA, FD00::53?
Needs an acronym ... off the top of my head, something like ASPEN -
Anycast Service Provisioning for Enterprise Networks ... ?
(Although it could be appropriate for an ISP-HomeUser as well ... hmmm,
SPATULA - Service Provisioning -
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 prefix:::1
FWIW - I think simple anycast fits that bill.
I think for very small/small networks anycast
Owen DeLong wrote:
On Oct 22, 2009, at 4:27 PM, Joe Maimon wrote:
NAT wasnt a component of IPv4 until it was already had widespread
adoption. I remain completely unconvinced that people will not
continue to perceive value in PAT6 between their private and their
public subnets.
People may
On Oct 23, 2009, at 5:08 AM, Perry Lorier 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
prefix:::1 I personally would suggest getting a well
On Oct 23, 2009, at 5:45 AM, TJ 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
prefix:::1
FWIW - I think simple anycast fits that bill.
Once upon a time, Owen DeLong o...@delong.com said:
Please remember that IPv6 DNS is OFTEN not stateless as the replies
are commonly too large for UDP.
Anything that supports IPv6 _should_ also support EDNS0.
--
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet
I figured was a good candidate since it's already partially in use
for
reserved special addresses.
But in a totally non-routable fashion, as it stands today.
ULA's have the immediate benefit of being routable, but not globally so -
and (hopefully) already being in filter lists to
On Fri, Oct 23, 2009 at 12:50:47PM +1300, Perry Lorier wrote:
I've implemented myself a system which firewalled all ARP within the AP and
queried the DHCP server asking for the correct MAC for that lease then sent
the ARP back (as well as firewalling DHCP servers and the like). It's
quite
I think for very small/small networks anycast requires a lot of overhead
and understanding. If your big enough to do anycast and/or loadbalancing
it's not hard for you to put all three addresses onto one device.
Anycast isn't really hard - same address, multiple places, routers see
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
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 hosts
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
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 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 know
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 wouldn't
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 fairly
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 not
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
I point you
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
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 a
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
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.
Another
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
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 operators -
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
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
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
2009 00:22:52
To: bmann...@vacation.karoshi.com
Cc: nanog@nanog.org
Subject: Re: IPv6 Deployment for the LAN
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
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 you want
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
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
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 crap.
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
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
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
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
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 other
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'll
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
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.
--
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 bickn...@ufp.org wrote:
In a message written on Thu, Oct 22, 2009 at 03:42:19PM
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 useful
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
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
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
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
On Thu, 22 Oct 2009 21:20:11 +1100
Karl Auer ka...@biplane.com.au 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,
Original Message
From: Ray Soucy r...@maine.edu
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
On Thu, 22 Oct 2009 11:40:50 +0200
Iljitsch van Beijnum iljit...@muada.com 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
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
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
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 default on
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
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
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
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
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 supposed to
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 does
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
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, K.
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
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
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 prefix:::1 I
personally would suggest getting a well known ULA-C allocation assigned
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
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 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 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 prefix:::1
I personally would
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 prefix:::1
FWIW - I think simple anycast fits that bill.
I personally would suggest getting a well known
On 18 okt 2009, at 5:51, Karl Auer wrote:
Do the advertisements right, advise sysadmins that hosts should
not do
SLAAC,
Doesn't it tell you something that you're fighting this hard to avoid
hosts from doing what comes naturally?
It occurs to me that I haven't met anyone who uses the
On 18 okt 2009, at 10:03, Andy Davidson wrote:
Support default-routing options for DHCPv6 !
This would be a big mistake. Fate sharing between the device that
advertises the presence of a router and the device that forwards
packets makes RAs much more robust than DHCPv4. And DHCPv6 is just
Iljitsch,
On Oct 21, 2009, at 12:46 PM, Iljitsch van Beijnum wrote:
On 18 okt 2009, at 10:03, Andy Davidson wrote:
Support default-routing options for DHCPv6 !
This would be a big mistake. [...] It's time for this DHC stuff to reach its
final resting place.
I'm curious: are you anticipating
On Oct 21, 2009, at 12:46 PM, Iljitsch van Beijnum wrote:
On 18 okt 2009, at 10:03, Andy Davidson wrote:
Support default-routing options for DHCPv6 !
This would be a big mistake. Fate sharing between the device that
advertises the presence of a router and the device that forwards
On 21 okt 2009, at 21:50, David Conrad wrote:
On Oct 21, 2009, at 12:46 PM, Iljitsch van Beijnum wrote:
On 18 okt 2009, at 10:03, Andy Davidson wrote:
Support default-routing options for DHCPv6 !
This would be a big mistake. [...] It's time for this DHC stuff to
reach its final resting
I respectfully disagree. In my opinion there is no future for IPv6
that doesn't involve DHCPv6. DHCPv6 is part of the design of IPv6 as
is clear by the existence of M, O, and A flags in RA.
Without DHCPv6, SLAAC has no way to provide DNS (or other)
configuration information, the fact that IPv6
On 21 okt 2009, at 21:55, Owen DeLong wrote:
However, making it available as an option in DHCPv6 allows the end-
user/operator
to choose the technology that fits their needs best. I do not know
why you are so
determined to prevent this choice at the operator level.
For the same reason that
On Oct 21, 2009, at 1:08 PM, Ray Soucy wrote:
Without DHCPv6, SLAAC has no way to provide DNS (or other)
configuration information, the fact that IPv6 was designed in a way
where SLAAC could be used for addressing and DHCPv6 for other
configuration is an example of how DHCPv6 is an integral
Once upon a time, Iljitsch van Beijnum iljit...@muada.com said:
What we need is a thing that gives us what we need to
connect to the network (addresses, DNS servers) and then a pointer in
the form of an HTTP or HTTPS URL for all other configuration.
You want to invent yet _another_ form of
On 21 okt 2009, at 22:23, Chris Adams wrote:
What we need is a thing that gives us what we need to
connect to the network (addresses, DNS servers) and then a pointer in
the form of an HTTP or HTTPS URL for all other configuration.
You want to invent yet _another_ form of configuration
We have networks and businesses to run. Why are we rehashing this yet
again?
For example, in December 200l http://www.merit.edu/mail.archives/nanog/2007-12/msg00280.html
shows messages regarding exactly this issue. for emphasis I
redundantly requote, You have seen this before from me:
What we have now is not a mess. What we have is a solid base to build
on. The problem is in education, the fact that both stateless and
stateful configuration are valid components to IPv6 for example, and
proper implementation by vendors.
There are a few challenges with IPv6 that need to be
On Oct 21, 2009, at 1:08 PM, Iljitsch van Beijnum wrote:
On 21 okt 2009, at 21:55, Owen DeLong wrote:
However, making it available as an option in DHCPv6 allows the end-
user/operator
to choose the technology that fits their needs best. I do not know
why you are so
determined to prevent
On Oct 21, 2009, at 1:05 PM, Iljitsch van Beijnum wrote:
On 21 okt 2009, at 21:50, David Conrad wrote:
On Oct 21, 2009, at 12:46 PM, Iljitsch van Beijnum wrote:
On 18 okt 2009, at 10:03, Andy Davidson wrote:
Support default-routing options for DHCPv6 !
This would be a big mistake. [...]
- Original Message
From: Iljitsch van Beijnum iljit...@muada.com
Then again, if we remove all the improvements from IPv6 what's the point of
adopting it?
How about IPv4 address depletion?
I'm perfectly happy with how my network works. I do, however, want it to keep
growing, and this
1 - 100 of 141 matches
Mail list logo
