Hi Teemu,
I read your proposal and have been thinking about it. I'd like to share some of
my thoughts as feedback for you.
My thoughts are a bit random and not well-organized.
They are also many in number. Sorry about that.
First let me say that I do see increased prevalence of network interfaces
This is interesting. Thanks for doing these tests and submitting the results.
When testing the switching behavior, I'm curious for the " SLAAC-only host
receiving A=0&M=1 " case as to what you set the Preferred Lifetime to, when you
set A=0. I'm guessing Preferred Lifetime > 0?
Since RFC 4862 st
> Just I mentioned in previous email, SLAAC is optional WiMAX deployment.
The attempt to create an access network without RA/RS is nothing new.
Other (e.g., DSL, PON) access network technologies have considered this and
determined that the biggest missing piece is route info. Which is the reason
If an LV never ever wanted to get a PD from anything other than an IV, and an
IV could only ever expect to delegate to a LV, then I see no problem. On the
other hand, if these things do expect the same physical links to be used to
connect with other ecosystems (like home networks or hotspots) th
> My question is: what happens if any of them discovers that it has created an
> address that is already in use in the network?
>
> There would appear to be two options:
> (1) "ah, OK, I guess I didn't really want to talk today"
> (2) Following RFC 4941, guess again until one creates a unique addr
I think the rules for which (temporary vs not temporary) to use should be
application-specific. And the people who are best-positioned to determine
what's right for the app are the app developers or designers. Not IETF.
I vote for 3484bis to remain silent as to a preference, but to provide guida
I'm very much opposed to extending RA for this purpose. Having 2 ways to do the
same thing serves to increase complexity of the overall ecosystem. Unless you
can guarantee that the 2nd method will only ever be used in a closed system
(network manager consciously knows that this is the mechanism
> +1. It's highly unlikely that an SP wants to field DHCPv6
transactions
> from all the devices in a subscriber network. We have adequate
> mechanisms in place to get delegated prefixes and other config
> information to the DHCPv6 server in the subscriber network without the
> DHCPv6 relay functi
I'm unaware of any member of the mass market community (which accounts
for a whole lot of "nodes" and "routers") who are asking for or wanting
or expecting DNCP Relay. That's SOHO, Consumer, or the ISPs that serve
them. Are there specialized niches inside these communities that might
like DHCP Rela
It's fine.
Barbara
> -Original Message-
> From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf
> Of steve.dot...@cox.com
> Sent: Tuesday, October 19, 2010 4:01 PM
> To: f...@cisco.com; v6...@ietf.org; i...@ietf.org
> Cc: i...@core3.amsl.com
> Subject: Re: [v6ops]Fwd: I-D
C vs. RA text
>
> On 7/24/10 11:36 PM, Antonio Querubin wrote:
> > On Fri, 23 Jul 2010, STARK, BARBARA H (ATTLABS) wrote:
> >
> >> I would prefer if nodes were required (MUST) to support one or the
> other
> >> mechanism for DNS config. Given SLAAC is a must
> To summarize, the current document
> - retains SLAAC as a MUST
> - lists DHC (for address config) as a MAY
> - makes DHC for other configuration a SHOULD.
> - lists rfc5006bis (DNS RA Config) as a SHOULD
I would prefer if nodes were required (MUST) to support one or the other
mechanism for
> Do you think that the service type of
> the prefix should be classified to the prefix related configuration or
not?
> If yes, do you agree that it should be carried in RA in the stateless
> case?
Nobody is disagreeing that *if* we could turn the clock back 10 years or
so and have a greenfield di
+1
I completely agree with what Mark said here.
Barbara
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf
Of
> Mark Smith
> Sent: Monday, June 14, 2010 2:16 AM
> To: Fortune HUANG
> Cc: ipv6@ietf.org
> Subject: Re: Question about SLAAC: how the hos
Frank,
Yeah, I think that after the bloody simple-security debates of the past
week, that many are amazed that anyone on this list was able to miss the
carnage. Anyway, the current CPE router draft has the following security
requirements in section 4.4:
S-1: The IPv6 CE router SHOULD support
I'm sorry if the following questions show my ignorance, but, here
goes...
Why does it need to be a dynamic routing protocol? Why not a simple
configuration protocol, like with RFC 4191 or a DHCPv6 option as
suggested in
http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-01?
Why do the peer
Could someone confirm the name of the jabber room? My client tells me that
"v4v6existence" doesn't exist.
Barbara
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Wing
Sent: Tuesday, September 30, 2008 7:49 AM
To: 'Narayanan, Vidya'; 'Mark Townsley'; '
17 matches
Mail list logo
