Hi Suresh,
On 2011/06/29, at 4:32, Suresh Krishnan wrote:
> Hi Tim,
> There is already a programmatic switch for this in RFC5014
> (IPV6_PREFER_SRC_TMP/IPV6_PREFER_SRC_PUBLIC). Applications wishing to
> override system policy may do so by using this API.
Yes. An application can control which
I'm fine with this text.
Jari
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
By way of introduction, I have a preference for standards text to be as short
as possible, because the more we say, the more likely we are to be wrong
(especially when speculating about future router design). So here is my
next proposal for the text about routers setting the flow label. As always,
> > That all said, any router that sees a Flow Label of zero, and wants to
> > change it to something better presumably should/can. When would that
> > NOT be the case?
> If the network manager of the site decides not to do it there? I think
> it needs to be configurable.
Absolutely, and by defau
On 2011-06-28 11:40, Jari Arkko wrote:
> I still have an uneasy feeling about the changing flow IDs across the
> same TCP session. It feels wrong.
>
> That being said, Ran's argument that different classifications for
> fragmented/non-fragmented packets already happening for load-balancing
> reaso
On 2011-06-29 01:12, Thomas Narten wrote:
> Jari Arkko writes:
>
>> Bob,
>
In addition, I'm not sure I understand how a router knows that it
is a first hop router.
>
> IMO, this is not necessarily intended to be something routers just
> know automatically. The point is that routers cl
On 2011-06-29 01:06, Thomas Narten wrote:
> Brian E Carpenter writes:
>
>>o The deployment of this option MUST be consistent with [RFC4311].
>
>> [BC: This last sentence is to cover Jari's point about a router knowing it's
>> appropriate for it to set the label.]
>
> Could you please expla
Hi Tim,
There is already a programmatic switch for this in RFC5014
(IPV6_PREFER_SRC_TMP/IPV6_PREFER_SRC_PUBLIC). Applications wishing to override
system policy may do so by using this API.
Cheers
Suresh
From: ipv6-boun...@ietf.org [ipv6-boun...@ietf.or
All,
The NomCom Chair needs more volunteers...
Regards,
Brian
Original Message
Subject: Please help the Nomcom
Date: Fri, 24 Jun 2011 11:35:13 -0700 (PDT)
From: NomCom Chair
To: Working Group Chairs
Hi WG chairs,
We have had a good response to the first call for volunt
The second issue is surrounding IPv6 privacy addresses (RFC4941).
Section 3.1 of RFC4941 states:
"this document assumes that when a node initiates outgoing
communication, temporary addresses can be given preference over
public addresses when the device is configured to do so.
[ADDR_SELE
The third issue is I think one that Mark Smith raised, and there was some
discussion without a conclusion.
Do we add a rule between 3 and 4 saying 'Prefer greatest preferred lifetime',
i.e. If the addresses SA and SB both have non-zero value preferred lifetimes
(are "non-deprecated"), prefer t
Hi,
The authors of rfc3484-bis would like to solicit feedback on three open issues,
to help shape a (hopefully) final update before the cut-off on 11th July.
The first issue is which deprecated prefixes to include in the new default
policy table. As of -03, the 3ffe::/16 prefix has been remove
Jari Arkko writes:
> Bob,
> >> In addition, I'm not sure I understand how a router knows that it
> >> is a first hop router.
IMO, this is not necessarily intended to be something routers just
know automatically. The point is that routers closer to the source
tend to have better knowledge about
Brian E Carpenter writes:
>o The deployment of this option MUST be consistent with [RFC4311].
> [BC: This last sentence is to cover Jari's point about a router knowing it's
> appropriate for it to set the label.]
Could you please explain what the above is intended to do? I don't see
right
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 : Distributing Address Selection Policy using DHCPv6
Author(s) : Arifumi Matsumoto
15 matches
Mail list logo
