On Thu, 12 Aug 2010, Alain Durand wrote:
It probably depend on what kind of router.. If you only have point
to point link, what is the value of mandating to implement
redirects?
I've yet to see a router that only implements point-to-point
interfaces.
--
Pekka Savola "You eac
On 2010-08-13 13:32, Alain Durand wrote:
> On Aug 12, 2010, at 6:55 PM, Brian E Carpenter wrote:
>
>> Isn't this a case where what we really want is MUST implement and SHOULD
>> enable?
>>
>> If I bought a router, I would expect it to be capable of redirecting but
>> I might want to disable it.
>
On Aug 12, 2010, at 6:55 PM, Brian E Carpenter wrote:
> Isn't this a case where what we really want is MUST implement and SHOULD
> enable?
>
> If I bought a router, I would expect it to be capable of redirecting but
> I might want to disable it.
It probably depend on what kind of router.. If
Folks,
I have just published an Internet-Draft entitled "Security Assessment of
the IPv6 Flow Label" that analyzes the security implications of the Flow
Label header field, and proposes a scheme to set the Flow Label that is
compliant with RFC 3697, and compatible with
draft-blake-ipv6-flow-label-
On Aug 12, 2010, at 3:55 PM, Brian E Carpenter wrote:
> Isn't this a case where what we really want is MUST implement and SHOULD
> enable?
>
> If I bought a router, I would expect it to be capable of redirecting but
> I might want to disable it.
Makes sense to me.
Bob
>
> Regards
> Brian
Isn't this a case where what we really want is MUST implement and SHOULD enable?
If I bought a router, I would expect it to be capable of redirecting but
I might want to disable it.
Regards
Brian
On 2010-08-13 07:47, Alain Durand wrote:
> I have a question about draft-ietf-6man-node-req-bis-0
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 text on
Neighbor Discovery, ie RFC48
Hi,
I support the adoption of this document as WG draft.
The described solution is used in the proposal "Duplicate Address
Detection Proxy"
(http://tools.ietf.org/html/draft-costa-6man-dad-proxy-00) to avoid
multicasted messages (i.e. flooding) in a VLAN.
Best regards.
JMC.
2010/7/31 Fred Baker
Yes, Rémi, you are.
We have explained that inserting data requires a new header and thus IP in IP
encapsulation. This happens for instance when a packet comes from the Internet
into a RPL network. Which we can hardly accept in constrained networks an
devices. In most cases, we could squeeze the
Le 12 août 2010 à 04:02, Brian E Carpenter a écrit :
> On 2010-08-12 11:34, Philip Levis wrote:
>> On Aug 10, 2010, at 11:12 PM, Rémi Després wrote:
>>
>>> Le 10 août 2010 à 18:09, Michael Richardson a écrit :
>>>
> "Rémi" == Rémi Després writes:
Rémi> RFC 3697 isn't concerned wi
Le 12 août 2010 à 10:47, Pascal Thubert (pthubert) a écrit :
> We'll note that the Hop by Hop + IP in IP is costly but
> solves the generic problem *within* the RPL network. The use of the Flow
> label *within* the RPL network would be an alternate so it could have a
> more limited applicability,
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance Working Group of the IETF.
Title : IPv6 UDP Checksum Considerations
Author(s) : G. Fairhurst, M. Westerlund
Filename: d
> >>
> >>Pascal> [Pascal] The FL based proposal for RPL uses 12 mutable
> > bits.
> >>
> >>Pascal> They are used as an in-band control plane that checks
the
> >>Pascal> consistency of routing states along a path. Those states
> > can
> >>Pascal> easily get out of sync due to the nat
13 matches
Mail list logo
