> yes. this seems like a case of something that looked like a great idea
> 12+ years ago (rfc2461 was published in 1998, LOTS of things have
> changed since that time) but is upon reflection maybe not a great
> idea.
>
> Directed Broadcast is a super example of this same thing (perhaps not
> rfc
On Thu, Aug 19, 2010 at 6:25 PM, Jared Mauch wrote:
> We disable them. We wish our vendors would expose these hidden defaults in
> their codebase (nvgen, etc).
>
> Just because it is in an rfc does not make it right :-) it should be changed.
yes. this seems like a case of something that looked l
> For the 4th time to this mailer. What do you do with shipping routers
> as of 10 years back that have Redirect enabled by default because of
> the SHOULD in RFC 2461 and RFC 4861?
standards work != archeology
IETF IPv6 working
Hi Brian,
Thanks for the comments. I will submit a revised version tomorrow.
On 10-08-19 12:26 PM, Brian Haberman wrote:
Suresh,
On 8/19/10 9:43 AM, Suresh Krishnan wrote:
Hi Woj,
On 10-08-19 09:22 AM, Wojciech Dec wrote:
There seems to be reason to explain the context/workings more clearl
Joel,
Ccing your reply to a broader audience. I understand reason A below but
with a grain of salt. I know for example, the deprecation of the RH0
header as such a change. So the grain of salt is, I don't recommend the
IETF waffle without a formal document that captures the reason for the
chang
We disable them. We wish our vendors would expose these hidden defaults in
their codebase (nvgen, etc).
Just because it is in an rfc does not make it right :-) it should be changed.
Jared Mauch
On Aug 19, 2010, at 6:00 PM, "Hemant Singh (shemant)" wrote:
> For the 4th time to this mailer.
For the 4th time to this mailer. What do you do with shipping routers as of 10
years back that have Redirect enabled by default because of the SHOULD in RFC
2461 and RFC 4861? Why is this point so hard to understand or being ignored?
Hemant
-Original Message-
From: ipv6-boun...@ietf.o
On Thu, Aug 19, 2010 at 4:22 PM, wrote:
>> > Redirects are a key part of the Internet architecture. Always have
>> > been.
>>
>> Not sure if you actually looked at the configuration sampling I posted, but
>> redirects are not actually used in networks these days. The only places
>> where i've
> > Redirects are a key part of the Internet architecture. Always have
> > been.
>
> Not sure if you actually looked at the configuration sampling I posted, but
> redirects are not actually used in networks these days. The only places
> where i've seen it used are in "hacked together" networks
On Aug 19, 2010, at 3:00 PM, Thomas Narten wrote:
> Jared Mauch writes:
>
>
>> On Aug 16, 2010, at 5:43 AM, Mark Smith wrote:
>
>>> It seems to me that arguing against redirects is actually arguing for
>>> having a common case, rather than an transient one, of nodes that don't
>>> have full o
On Aug 19, 2010, at 3:50 PM, Ralph Droms wrote:
> Being a little pedantic here...my understanding is that a host never knows a
> subnet length, per se. What the host knows is a list of on-link prefixes,
> which it matches against outbound traffic. A minimal implementation might
> not keep a
> Being a little pedantic here...my understanding is that a host never knows a
> subnet length, per se. What the host knows is a list of on-link prefixes,
> which it matches against outbound traffic. A minimal implementation might
> not keep a list of on-link prefixes and send everything to it
Being a little pedantic here...my understanding is that a host never knows a
subnet length, per se. What the host knows is a list of on-link prefixes,
which it matches against outbound traffic. A minimal implementation might not
keep a list of on-link prefixes and send everything to its defaul
On Aug 19, 2010, at 3:07 PM, Thomas Narten wrote:
> Brian E Carpenter writes:
>
>> Jared,
>
>> On 2010-08-16 13:06, Jared Mauch wrote:
>> ...
>
>>> Is there a legitimate operational reason a host should not know
>>>the subnet length it sits on?
>
> A host should not be *required* to know
Brian E Carpenter writes:
> Jared,
> On 2010-08-16 13:06, Jared Mauch wrote:
> ...
> > Is there a legitimate operational reason a host should not know
> > the subnet length it sits on?
A host should not be *required* to know the subnet length. Very
simple devices may have "simple" stacks.
Jared Mauch writes:
> On Aug 16, 2010, at 5:43 AM, Mark Smith wrote:
> > It seems to me that arguing against redirects is actually arguing for
> > having a common case, rather than an transient one, of nodes that don't
> > have full onlink prefix knowledge. I think having all nodes attached to
Alain Durand writes:
> I have a question about draft-ietf-6man-node-req-bis-05.txt.
> Section 5.2:
>Redirect functionality SHOULD be supported. If the node is a router,
>Redirect functionality MUST be supported.
> However, draft-ietf-6man-node-req-bis-05.txt refer to the normative
> te
Suresh,
On 8/19/10 9:43 AM, Suresh Krishnan wrote:
> Hi Woj,
>
> On 10-08-19 09:22 AM, Wojciech Dec wrote:
>> There seems to be reason to explain the context/workings more clearly,
>> both in terms of multicasting an RA and the overall expected BBF usage.
>
> The draft describes how the sender o
Hi Woj,
On 10-08-19 09:22 AM, Wojciech Dec wrote:
There seems to be reason to explain the context/workings more clearly,
both in terms of multicasting an RA and the overall expected BBF usage.
The draft describes how the sender of the RA deals with a tunneled RS
with a LIO. No RS received, no
Hi Ole,
On 10-08-19 09:01 AM, Ole Troan wrote:
Alan,
Don't you have that same problem regardless of the LIO?
If you have an IPv6 host directly connected to say your loving Residential Gateway and it sends 3 RS messages you have the same issue, right?
Also, the likelihood of losing 3 RS mes
There seems to be reason to explain the context/workings more clearly, both
in terms of multicasting an RA and the overall expected BBF usage.
-Woj.
On 19 August 2010 15:07, Alan Kavanagh wrote:
> Hi Ole
>
> So I see two tracks here, as I noted last year in BBF. 1. You sent the RA
> periodicall
Hi Ole
So I see two tracks here, as I noted last year in BBF. 1. You sent the RA
periodically multicasted for the defautl router address advertisement. In this
you can also multicast a Prefix as would be the case in some situations, i.e.
hotspot deployments connected over a TR-101 network. 2. T
Alan,
> Don't you have that same problem regardless of the LIO?
>
> If you have an IPv6 host directly connected to say your loving Residential
> Gateway and it sends 3 RS messages you have the same issue, right?
>
> Also, the likelihood of losing 3 RS messages are highly unlikely, you would
> > then you will join us supporting the /127 document and it won't be a
> > problem, will it.
> >
>
> Why won't you and the other authors do a proper job with it then? It
> doesn't address all the implications that arise. It should, point by
> point address, all the issues in RFC3627. It should a
Hi Pekka,
>> It seems that the point is not really that of reduced performance,
but
>> rather that complying with this requirement would require a change in
>> the silicon?
>>
>> If that's the case (i.e., no real performance implications), then it
>> looks like an appropriate fix for this issue. -
Hi Woj
Don't you have that same problem regardless of the LIO?
If you have an IPv6 host directly connected to say your loving Residential
Gateway and it sends 3 RS messages you have the same issue, right?
Also, the likelihood of losing 3 RS messages are highly unlikely, you would
have better p
SInce the WG is being asked to adopt a draft it would seem rather natural to
explain the context of the usage more clearly, especially as it appears that
this usage context has a rather serious pitfall when used alongside a
regular IPv6 client (leaving such a client with no connectivity after an RS
All,
The minutes from the 6MAN sessions in Maastricht have been posted:
http://www.ietf.org/proceedings/78/minutes/6man.txt
Please review and let the chairs know of any errors/omissions.
Regards,
Brian & Bob
IETF IPv6 work
28 matches
Mail list logo
