I support the adoption of this document.
- Alain.
-
All,
I am starting a one week consensus call on adopting:
Title : Using 127-bit IPv6 Prefixes on Inter-Router Links
Author(s) : M. Kohno, et al.
Filename : draft-kohno-ipv6-prefixlen-p2p-03.txt
Pages
On Aug 25, 2010, at 9:11 PM, Christopher Morrow wrote:
So, back to:
1) should implement redirect
2) should NOT enable by default
right?
This is what I'm after.
- Alain.
IETF IPv6 working group mailing list
On Aug 19, 2010, at 2:23 PM, Thomas Narten wrote:
The reality is that the Internet ecosystem has a wide variety of
devices now, and many don't cleanly fit into either category. Even
routers are hosts, when they act as the sender or originator of
traffic.
Even with routers, this thread
On Aug 19, 2010, at 3:00 PM, Thomas Narten wrote:
If you have 2 routers on the link, a host will choose one (at random)
and forward traffic to it. If the host guesses wrong (for a particular
destination), the router should send a redirect directing the host to
use the other router instead
On Aug 20, 2010, at 10:06 AM, Christian Huitema wrote:
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.
As codified 12 years
networks.
- Alain.
On Aug 24, 2010, at 12:22 PM, Hemant Singh (shemant) wrote:
Alain,
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Alain Durand
Sent: Tuesday, August 24, 2010 11:20 AM
To: Christian Huitema
Cc: prevention; i
Why make things easy when we can make them complex...
- Alain.
On Aug 24, 2010, at 12:41 PM, Hemant Singh (shemant) wrote:
-Original Message-
From: sth...@nethelp.no [mailto:sth...@nethelp.no]
Sent: Tuesday, August 24, 2010 11:47 AM
To: Hemant Singh (shemant)
Cc:
On Aug 24, 2010, at 2:11 PM, Hemant Singh (shemant) wrote:
2) Even if redirect could be useful in such a leaf network, it would
not change my overall point. This is not an argument to mandate it
mandatory to implement for ALL networks.
So are you asking for the text like this to change
On Aug 13, 2010, at 1:57 AM, Pekka Savola wrote:
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
On 7/18/08 12:30 PM, Mark Townsley [EMAIL PROTECTED] wrote:
[4] http://www.ietf.org/proceedings/07dec/slides/v6ops-5/sld1.htm
For a more up to date reference, I would suggest to read:
http://www.ietf.org/internet-drafts/draft-durand-dual-stack-lite-00.txt
- Alain.
+1
On 3/13/08 6:44 PM, Francis Dupont [EMAIL PROTECTED] wrote:
Perhaps some of us didn't remember but:
- I predicted the RFC 3484 will be always at least a phase back from
what we want.
- I predicted too it would take a not reasonable amount of time to
get the document published or
sugestion seems too rough to change the consensus.
I would be happy if I see your evidence.
I hope that the records and the experiences described above
helps the discussion.
Thanks,
From: Alain Durand [EMAIL PROTECTED]
Subject: Making IPsec *not* mandatory in Node Requirement ( was Re
John,
Clarification: I am not talking about set top box, but cable modems. Very
different beast.
- Alain.
On 2/27/08 3:12 AM, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
Julien and Alain,
My high-level question to you both is, for sensors and set-top
boxes - do you feel that you do not
The latest draft: draft-ietf-6man-node-req-bis-00.txt
still lists IPsec as mandatory to implement.
As I mentioned last IETF meeting, this is creating a problem for certain
kind of devices, like cable modems, who have a very limited memory
footprint. Those devices operate in an environment where
Coming late into this discussion...
In our deployment which concern a very large number of devices (many
millions), we will use DHCPv6 only.
In our internal infrastructure, we are planning to use mostly DHCPv6 on
servers and manual config for anything where DHCPv6 may not make sense, eg
routers.
Whatever the IETF decides, implementers are free to implement what they want
and network managers are free to deploy what they want the way they want.
Ie, devices that may or may not implement DHCPv6.
Some devices that have DHCPv6 implemented could be configured to ignore
completely the M bit and
On 9/28/07 12:42 PM, james woodyatt [EMAIL PROTECTED] wrote:
On Sep 28, 2007, at 07:01, Alain Durand wrote:
0% stateless autoconf.
Do you mean there will be router advertisements with M=1 and one or
more prefix information options with A=0?
* It will depend. Some places may
On 8/20/07 4:00 PM, Brian Haberman [EMAIL PROTECTED] wrote:
I believe the wording allows us to add work items that the WG wishes to
adopt.
I believe this is the wrong thing to do for any wg in general and for a
maintenance¹ wg in particular.
The charter is a contract between the wg and
===
CHAIRS: Alain Durand [EMAIL PROTECTED]
Thomas Narten [EMAIL PROTECTED]
AGENDA:
Problem space:
- Administrativia (2 min)
Alain Durand Thomas Narten
- Problem statement (10 min)
Thomas Narten
- v6ops initial combine goals (10 min)
Jordi
draft
On Jan 24, 2005, at 3:14 PM, Jari Arkko wrote:
Erik Nordmark wrote:
I wonder whether Experimental wouldn't send a clearer signal
that there is some doubt about the viability of the solution.
That would be better than informational.
I agree. But I also think that if the document has
inconsistencies
On Jan 27, 2005, at 6:02 AM, Brian E Carpenter wrote:
Alain Durand wrote:
...
The argument that NDproxy will only be used in a certain environments
where SEND is not needed is clearly bogus, The IETF is not about
defining standards for special cases but for the whole Internet.
I disagree
On Dec 8, 2004, at 6:27 AM, Brian Haberman wrote:
This is unfortunately not the only concern. Actually, i would even
say this is
a somehow minor issue, as the risk of collision is small.
The real concern is similar to what is explain in the v6ops
IPv6onbydefault draft.
Say that a well know host
Hi,
I couldn't find any mention of RFC2526 Reserved IPv6 Subnet Anycast
Addresses
in the node requirement document.
Is it OK for an IPv6 node to ignore it? in practice, should/must an
implementation
have some code to:
1- prohibit such addresses to be configured on an interface
2- make sure that
On Dec 7, 2004, at 1:23 PM, Bob Hinden wrote:
While I am sure everyone in this discussion has read the DNS text in
the current draft, here it is just in case:
4.4 DNS Issues
At the present time and PTR records for locally assigned local
IPv6 addresses are not recommended to be
On May 17, 2004, at 2:09 AM, Christian Strauf (JOIN) wrote:
Jinmei,
Explicit support or objections are highly appreciated. If the list is
still silent, I'll start revising the document anyway.
I support all of your proposed changes.
Same here.
- Alain.
On May 3, 2004, at 5:59 AM, Bernie Volz wrote:
You can certainly have hosts that always run DHCPv6, or at least policy
settings that would allow it on a host.
Or the opposite... That is, hosts that have a policy to not turn DHCPv6
on
even when receiving O or M.
- Alain.
(B (BOn Apr 29, 2004, at 10:29 AM, Tim Chown wrote: (B (B (BOn Thu, Apr 29, 2004 at 06:12:02PM +0300, Pekka Savola wrote: (B (BOn Thu, 29 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] (B[EMAIL PROTECTED]@C#:H(B (Bwrote: (B (B- details of the relationship between each flag and protocol,
(B (BOn Apr 27, 2004, at 11:49 PM, JINMEI Tatuya / (B[EMAIL PROTECTED]@C#:H(B (Bwrote: (B (BOk, thanks for the clarification. IMHO, it is not OK (Bto keep (B (Bthe document as DS with OM given the general lack of implementation. (B (B (B (BHmm, this message of yours seems to have
On Apr 27, 2004, at 2:21 AM, Tim Chown wrote:
On Mon, Apr 26, 2004 at 10:14:02AM -0700, Alain Durand wrote:
Let me try to explain why I, as an implementor, do not like the M/O
bits very much.
...
Alain,
Could you explain how the functionality of the O/M bits will be
replaced
within the ND/etc
On Apr 28, 2004, at 9:29 AM, Christian Huitema wrote:
I think a whole lot of the issue has to do with the supposedly
mandatory nature of the M flag, which leads to phrases like do DHCP,
and only if it fails do auto-config. It would be much simpler to
simply define the flags as announcing an
(B (BOn Apr 26, 2004, at 11:29 PM, JINMEI Tatuya / (B[EMAIL PROTECTED]@C#:H(B (Bwrote: (B (BI would first like to be sure if it is okay to recycle the (Bdocument as (B (BDS even with the lack of implementation on a part of the protocol (B (Bdescription (in this case, the receiving
On Apr 27, 2004, at 1:50 AM, Soliman Hesham wrote:
The facts are:
1. there is code that sets the MO bits. (router implementations)
2. there are at least two implementations that read and
act on the O
bit. These two implementations both invoke stateless DHCPv6 as
the action.
= So
(B (BOn Apr 26, 2004, at 10:09 PM, JINMEI Tatuya / (B[EMAIL PROTECTED]@C#:H(B (Bwrote: (B (B (BMy biggest question is: can we recycle rfc2462bis as DS (Bdespite fact (B (B3? (B (B (B (BI failed to see what is wrong with the unused feature elimination (BChristian described (B
On Apr 26, 2004, at 10:02 PM, S. Daniel Park wrote:
To give a hint that DHCPv6 is present?
Don't you consider this useful?
I have no hard stance whether to remove MO bits
or not at this stage, however if we remove it, I
guess somebody will sporadically define similar
flags into the RA repeatly so
Jinmei,
I agree with your analysis, except that I'm not so much worried about
breaking somebody's assumption in designing an hypothetical client
dealing with the O/M bits. The definition of those bits was obscure
in 2462 anyway.
I would be more worried if this was to result in demonstrated
be
considering deprecating it. Please take this into consideration in
your
discussions.
Regards,
Brian Russell
Systems Engineer
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Alain
Durand
Sent: Friday, April 23, 2004 11:19 AM
To: JINMEI Tatuya / ?_-?'B
On Apr 22, 2004, at 9:08 AM, Thomas Narten wrote:
Based on the above, my understanding is that your appeal has now been
resolved.
Thomas,
Thank you for organizing the con-call that enable us to make those
progress.
The steps you mentioned address fully my concerns and resolve my appeal.
I'm
I agree with Jim, section 5.5.2 should be deleted. Let implementations
decide
what to do if there is no router.
If you decide to keep 5.5.2, you will need to add some text to analyze
the performance impact of doing DHCPv6 when there is no IPv6 at all.
- Alain.
On Apr 17, 2004, at 9:11 PM,
I think that deprecating the O M bits will be good.
I'm not too worried about incompatibility, as most code
do not support those bits anyway. Also, it is mostly an
operational issue. All we need to do is to publish
a BCP saying essentially: Do not set the O M bits in RA
and we are done.
In
Ok, what would break if we were to declare the O M bit historic
and issue a BCP recommending not to set them in RA?
It is unclear to me what part of existing code would break
- Alain.
On Apr 15, 2004, at 12:08 PM, Tim Hartrick wrote:
I believe that it is entirely too late in the life of
On Apr 14, 2004, at 3:48 AM, Ralph Droms wrote:
Jinmei-san,
I think DHCPv6 ought to be cited as the protocol for other
configuration
information, as well.
This is the logical extension.
However, it seems to me the phrase stateful protocol for *other*
configurations is a little misleading. I
On Apr 14, 2004, at 10:11 AM, Ralph Droms wrote:
Followup on the meaning of stateless - one way to interpret
stateless in
the context of DHCPv6 is: does not require the maintenance of any
dynamic
state for individual clients (RFC 3736). The server does, of course,
maintain configuration state
JINMEI Tatuya / wrote:
Question A: how should rfc2462bis specify the stateful protocol?
possible answers:
1. clearly say that stateful address configuration is DHCPv6
2. (intentionally) do not say anything about this, and (implicitly
or explicitly) leave it to the node requirements
On Mar 18, 2004, at 8:47 AM, [EMAIL PROTECTED] wrote:
On 18 March 2004, Pekka Savola wrote:
The fact that there is a solution out there, which fits the
needs of some users, does not mean that there can not (or
should not) be a different kind of solution which would seem
to be much more
On Mar 15, 2004, at 12:57 AM, Stephen Sprunk wrote:
Thus spake Brian E Carpenter [EMAIL PROTECTED]
Margaret Wasserman wrote:
...
SUBSTANTIVE ISSUES:
(1) This draft doesn't mention the reverse DNS tree. Is it expected
that
whatever registry assigns these values will also populate the
On Mar 9, 2004, at 9:52 PM, Brian E Carpenter wrote:
Yes, I appologise for accidentally resurrecting the fixed charge,
by typing is suggested when my brain was thinking was suggested.
We did indeed all agree to delegate *that* choice to IANA.
This is the part that bothers me. If we delegate the
On Feb 24, 2004, at 10:48 AM, Brian Haberman wrote:
Alain,
At 01:22 AM 2/20/2004, Alain Durand wrote:
Dears ADs,
Since the appeal process starts with the working group chairs, we
are responding as such.
I found it very unfortunate that the chair decided to request to
advance this document
On Feb 24, 2004, at 10:09 AM, Fred Templin wrote:
Alain,
Speaking only as an individual wg participant, I appreciate the
concerns
you are raising but am hoping that you are not contemplating a divisive
and time-consuming appeals process such as the one we have just come
through for site local
Dears ADs,
I found it very unfortunate that the chair decided to request to
advance this document
without answering two major issues I raised during the last call:
- Permanent allocation is equivalent of selling address space, which is
very different from
the notion of stewardship that are
While doing those edits, why not also remove the dictate to give
permanent allocations from this document?
After all, this is also an operational/business discussion, not a
technical one.
- Alain.
On Feb 5, 2004, at 10:07 PM, Christian Huitema wrote:
From what I have read so far, the
) of
chunks of address space. This is a fundamental departure from what
has been done
in the past.
- Alain.
On Feb 6, 2004, at 1:19 PM, Tim Chown wrote:
On Fri, Feb 06, 2004 at 08:05:17PM +, Zefram wrote:
Alain Durand wrote:
While doing those edits, why not also remove the dictate
Brian Haberman wrote:
All,
This is the start of an IPv6 working group last call on:
Title : Unique Local IPv6 Unicast Addresses
Author(s) : R. Hinden, B. Haberman
Filename: draft-ietf-ipv6-unique-local-addr-02.txt
Pages : 16
Christian Huitema wrote:
Locally assigned global IDs MUST be generated with a pseudo-random
algorithm consistent with [RANDOM].
I would have like to see some stronger wording to explain that, in the
self assigned case,
choosing FD00::/48 is a very bad idea.
The draft already says that
On Dec 9, 2003, at 1:14 AM, Brian E Carpenter wrote:
But I think Keith's suggestion is correct - add in the text
descrription
prior to the normative statements. It's the best we can do, let's just
do it.
I could live with that.
- Alain.
The whole story about deprecating Site Local has led to very complex
discussions
that a lot of people had difficulties to follow, partly because the
issues are complex
and partly because of the heat of the debate.
As we are coming near to a conclusion to this painful story, I believe
we owe
Those are very good to mention as well.
- Alain.
Keith Moore wrote:
To the implementors:
a) don't implement SL if you are designing a new product
b) don't rush removing SL support from your current products, this can
be done in future releases.
to application implementors:
a)
[EMAIL PROTECTED] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.
Title : Deprecating Site Local Addresses
Author(s) : C. Huitema, B.
Catching up with things.
I support Christian objection 100%.
Protocols may be implemented in the stack but turned on/off by
configuration.
- Alain.
Christian Huitema wrote:
Also, I think we should revisit this text in the RFC2462bis
effort. Changing the MUST to MAY in the 5.5.2 paragraph
Tim Chown wrote:
I think we will see a lot of people using fd00::/48 or fd00::/64 for
their sites/links purely becuase it's less effort to type.
If this is the case, what will we have gained from fec0::/48?
One year of extremely heated discussion, appeal, gazillions
of email, just to
Zefram wrote:
Alain Durand wrote:
If this is the case, what will we have gained from fec0::/48?
The opportunity to avoid this numbering clash. Idiots who use fd00::/48
will clash with each other, but the rest of us avoid clashes with each
other and with the idiots.
If you look at RFC3513
I just watched the video of the site local deprecation presentation
from Christian Huitema.
There is one issue raised in the mailing list that Christian did not
mention,
that is the current deprecation section does not mention the list of
RFCs that are impacted.
I strongly object to the
Christian Huitema wrote:
4 Deprecation
This document formally deprecates the IPv6 site-local unicast
prefix
defined in [RFC3513], i.e. 111011 binary or FEC0::/10.
I think this section is not ready yet. Couple comments:
1) This is not the IETF job to mandate what an
Christian Huitema wrote:
Suggested text to address both comments:
The special behavior of this prefix MUST no longer be supported.
Well, we did not intend to force every implementation developer to go
fix the problem immediately, recall the products that have already
shipped, etc.
On Nov 4, 2003, at 12:48 AM, Tim Chown wrote:
On Mon, Nov 03, 2003 at 10:45:07PM -0800, Alain Durand wrote:
As I explain in a previous message, this last property is not verified
by the hinden/haberman draft, as when those addresses leak,
they would create untraceable problems, very similar
On Nov 4, 2003, at 10:00 AM, Tim Chown wrote:
How do we control or throttle the allocations and not regret it later?
With current IPv6 adoption we don't have a problem though... (!)
Exactly the point... The fear of a gold rush has been driving many
similar
discussions over the last few years. The
I think that this effort is not ready for prime time.
This document is creating a explosive cocktail made of:
- policy: creation of a new authority to perform address assignment
outside of the regular channels
- economy: imposition of a fixed one time fee model, preventing
competition
I had this question yesterday and I couldn't find an answer in RFC2460:
Is it valid for a host to send a packet with Hop Count set to zero?
- Alain.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative
67 matches
Mail list logo
