Christian,
SEC does not increases costs equally for both attackers and defenders. An
increase of time T for the defender correspond to an increase of time T*2^59
for the attacker.
Right. I was speaking about the relative effort increase. For Sec = 0, I have
to do 1 unit of work, the
Christian,
I would not construct the attack by trying random numbers and checking them
for whether they are a public key. I would start with a repository of prime
numbers, and then do something like:
I agree with this as well.
Jari
Is there a conclusion of this thread? My read of it is that no amount of
tweaking how you calculate the IID help the fact that in 59/62 bits you have a
limited space to search. The Sec scheme does help, but increases costs equally
for both attackers and defenders.
FWIW, I'm struggling to
Hosnieh,
What is it that you don't understand. I will be happy to explain it to you.
Thanks. I read the details, but I'm missing the big picture. I.e., some effort
is required from the owner to create an address. By repeating that effort
(2^59)/2 times, someone else is likely to hit the same
Well, I think it is quite a simple trade-off. Increasing Sec increases
computational effort on both sides by equal amount. Increasing the length of
the hash increases computational effort only on the attacker side. As a result,
the hash bits are relatively valuable.
The trade-off that we have
Christian,
Well, I think it is quite a simple trade-off. Increasing Sec increases
computational effort on both sides by equal amount. Increasing the length of
the hash increases computational effort only on the attacker side. As a result,
the hash bits are relatively valuable.
Jari, the
Director and thank him for his long service as 6man co-chair. I
am sure he will make an excellent AD and have enjoyed working with him in 6man.
Of course, I also want to thank Jari Arkko for his long and excellant service
as our Internet AD.
Ole Trøan will be the new 6man co-chair. Ole has
I have reviewed this document, and as it obviously was ready to be moved
forward, asked for an IETF Last Call to be initiated. Thanks for writing the
document.
Jari
IETF IPv6 working group mailing list
ipv6@ietf.org
The new version of this draft looks good to me:
http://tools.ietf.org/rfcdiff?url2=draft-gundavelli-v6ops-pmipv6-address-reservations-04.txt
Ready to be approved?
Jari
IETF IPv6 working group mailing list
ipv6@ietf.org
Good. Please make sure the RFC Editor gets the final AUTH48 change in e-mail so that I
can say approve...
Jari
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests:
I have reviewed this draft. It is ready to move forward, and I have requested a
last call to be initiated. In the meantime, I also had a few mostly editorial
comments that you may want to take into account:
Also, Several existing deployed IPv6 routers and several existing
get IANA to
understand also what they need to do in detail. I'm currently holding a Discuss
on their behalf, because the current instructions were unclear. Can you make
this happen by drafts deadline?
Jari
On 18.10.2011 21:29, Jari Arkko wrote:
The last call ended yesterday. We are fine
The last call ended yesterday. We are fine with going ahead as proposed
standard, but there were two other issues raised during discussion.
1. Possible draft to update RFC 5453 / 5342 to say that allocations in either
one should not conflict with each other. I tend to agree with Thomas that we
These options are ND options as specified in RFC 4861, which states:
Neighbor Discovery messages include zero or more options, some of
which may appear multiple times in the same message. Options should
be padded when necessary to ensure that they end on their natural
64-bit
Jonathan,
I think we have converged (one suggestion inline below though). Please submit
the draft.
Here are my comments in more detail:
Datagrams being forwarded within a RPL domain MUST include a RPL
Option. For datagrams sourced within a RPL domain, the RPL Option
MAHui,Y be included
Jonathan,
We have converged. Please make the changes and lets move the document forward.
jari
Hi Jari,
I think we are converging. If there are no other comments, we will update the
draft based on your review. See below:
On Sep 2, 2011, at 2:19 PM, Jari Arkko wrote:
Jonathan,
Please see
This draft is being last called for the second time, as it was discovered late
that we had missed an IANA requirement. Suresh Krishnan (author of the RFC 5453
registry for interface identifiers) noted that any allocations need to be made
in Proposed Standard RFCs, and I had taken the draft
Following up with a personal comment.
The draft allocates an interface ID and an EUI-64 MAC identifier from the IANA
block. These are two separate, unrelated allocations.
The main criticism in RFC 5453 for making additional interface ID allocations
is that old implementations do not know
Jonathan,
Please see inline. If you agree with what I'm writing here you should just
submit a new draft version and we can take it from there. But it might be that
on some aspects we need further discussion.
links within a RPL domain SHOULD have
a MTU of at least 1280 + 40 (outer IP header)
Jonathan,
Please see below. I think we are converging. The main remaining discussion item
below is the description of what the border router does.
Here are my comments in more detail:
Datagrams being forwarded within a RPL domain MUST include a RPL
Option. For datagrams sourced within a
JP, Jonathan,
Has there a been response to the two reviews from June? I'd like to move
these drafts forward...
Jari
Jari Arkko kirjoitti:
I have reviewed this draft. Some of the issues from the other draft
are visible in this one as well, and I saw two additional substantive
issues:
- we
I mentioned this draft on the mike line today:
http://tools.ietf.org/html/draft-arkko-core-sleepy-sensors
Implementing Tiny COAP Sensors
The authors are developing COAP and IPv6-based sensor networks for
environments where lightweight implementations, long battery
lifetimes, and minimal
Thomas, Brian,
Sure. But why should that impact how the Flow Label is rewritten from
zero to something else?
Because different routers might pick different labels for packets
that belong to the same flow.
Yes, that was my concern.
But, this implies packets from the same flow are
Good. Are we ready to send this to Last Call, or do we want to wait for
possible other comments from the working group?
Jari
Brian E Carpenter kirjoitti:
I believe this version resolves Jari's comments and the
subsequent discussion.
Brian
Original Message
Subject: I-D
I looked at Last Call time period and IESG telechat schedule and saw
that if we want this approved before the IETF, it needs to go to IETF
Last Call today. So I sent it in. If there are substantive comments from
the working group we can pull the document back for further
consideration in the
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
Bob,
In addition, I'm not sure I understand how a router knows that it is a first
hop router. Are there cases where a device might mistakenly believe it is a
first hop router at a point where the traffic has already been load-balanced to
multiple routers? Are there situations where the
I have reviewed this draft.
I think it is in good shape and can move forward once we resolve one
issue. Here's the issue:
A node that forwards a flow whose flow label value in arriving
packets is zero MAY change the flow label value. In that case, it is
RECOMMENDED that the forwarding node
Brian,
four bits from the flow label as reserved values
There was a pretty clear consensus against having any special bits, when
this sort of idea was discussed last year.
Ok. Was there a rationale, e.g., that it would be impossible to do so
for some reason, or that the bits could
I have reviewed this draft. It is well written, justifies its
recommendations and I believe it is ready to move forward. I have asked
for an IETF Last Call. However, I did see one editorial issue and one
technical issue that I would like you to discuss and correct if
necessary (even during the
Brian,
Personally, I think you're right. Should that be a normative SHOULD?
You were not using RFC 2119 language in this paragraph earlier either,
so I don't think it is needed.
We have a small handful of other minor edits that have come in since WGLC.
Do you want us to post a new
I have reviewed this specification. It is well written and ready to move
forward; I have asked for an IETF Last Call.
I did have two very minor editorial comments, and one personal opinion:
In this case too, the word
alone is to be interpreted precisely - a router is allowed to
combine the
I have reviewed this draft. Some of the issues from the other draft are
visible in this one as well, and I saw two additional substantive issues:
- we need to specify the behavior with regards to the data in this
option better
- the text about processing packets in RPL border routers should be
I have reviewed this draft.
I have a number of comments, most of which are at this point questions
and discussion items. The comments are included below in three
categories: technical comments, editorial comments, and comments
relating to feedback from other people that may not been fully
I have reviewed this draft. In general, this version is well written, I
agree with the recommendations, and I'd like to thank everyone for
working on this much needed update. I think the document is ready to go
to IETF Last Call -- some minor issues below that I think could be
addressed even
Thomas,
Hmm. I'd argue that moving and sleeping/waking nodes is perhaps more the
norm than exception today. At the very least, I'd again use the MAY
keyword for this specification. The above sounds almost like
recommending to not implement it.
Just how much time does 4429 shave of the
Got it. Thanks.
jari
Brian Haberman kirjoitti:
Jari Ralph,
On behalf of the 6MAN WG, the chairs request the advancement of:
Title : RPL Option for Carrying RPL Information in
Data-Plane Datagrams
Author(s) : J. Hui, J. Vasseur
Filename :
I have reviewed this specification.
I think it is ready to move forward, and I have requested last call to
be initiated.
However, while the last call is about to start, I did see one issue that
was also raised by a few of the reviewers in the working group
discussion. I think the document
Thanks. I will review it and move along.
Jari
Bob Hinden kirjoitti:
Jari Ralph,
On behalf of the 6MAN WG, the chairs request the advancement of:
Title : Using 127-bit IPv6 Prefixes on Inter-Router Links
Author(s) : M. Kohno, et al.
Filename:
I think that the only real world problem that I see today is the load
balancing. We should fix that.
Its hard to imagine that we'd really need full 20 bits for that. We
could even say use the last 16 bits for load balancing regardless of
what we decide to do about formal reserved/not reserved
Suresh,
I have reviewed your draft. A few comments below. Overall, I think its
not perfect but it is an acceptable solution to deal with the quirks of
the broadband access networks. I think the draft is ready for WG
adoption, and I support its adoption. However, there were a number of
Doug,
But it's not. ... We _really_ want to get this right NOW. Adding more
kludges so that we can Just get it deployed is actually going to
make life (and future deployment) harder down the road, not easier.
Agreed so far.
Suresh wants to support a particular type of a deployment, and it
Some of the discussion has gone into the history of IPv6 design, what
configuration model was intended by the original designers as the right
one, and so on. I would suggest that while that's interesting, it may be
secondary to what we are discussing here.
Suresh wants to support a particular
The latest version from Bob works for me, and I also agree this can be
done in AUTH48.
I also wanted to comment on the process. Sometimes we do hit issues in
AUTH48. Small changes, even technical, may be doable in AUTH48, but they
should always be confirmed with the working group, and
I have re-reviewed this document now that Bob passed it on to me for
submission to IESG and IETF level reviews.
I found three remaining issues:
1) RFC 1035 should be moved to be a normative reference.
2) The encoding of DNS search lists is underspecified:
Domain Names of DNS Search
-options-bis-03_txt.htm
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Jari Arkko
Sent: Wednesday, June 09, 2010 2:12 PM
To: draft-ietf-6man-dns-options-...@tools.ietf.org; IETF IPv6 Mailing List
Subject: AD review of draft-ietf-6man-dns-options-bis
I have re
Just as FYI, the document was updated and can now be reached from here:
http://www.ietf.org/internet-drafts/draft-ietf-6man-dns-options-bis-03.txt
Jari
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
Ah, good. Thanks for the update.
Jari
Tore Anderson kirjoitti:
* Jari Arkko
P.S. What would it take to make rdnssd a part of the default Linux
distribution? Its currently a separate piece that must be installed...
NetworkManager has over the last few weeks received
Thanks for writing this draft. I've read it and had a few comments:
The purpose of this document is to standardize IPv6 Router
Advertisement (RA) option for DNS configuration in IPv6 hosts
specified in [RFC5006] and also to define a new RA option for Domain
Name Search lists.
Maybe: ...
Hemant,
I am not sure I understand the "invented
prefix" case above.
IPv4 address assignment API's typically
assigns both an
address and a mask to an interface. One common implementation mistake
by
those familiar with IPv4 is to assume that an address carries a /64
prefix
length
I have reviewed this draft. The draft is in good shape and a welcome
clarification. However, I had two small issues I wanted to talk about
before moving the draft to last call:
5. Hosts MUST verify that on-link information is still valid after
IPv6 interface re-initialization before
This draft was on the IESG review yesterday, and did not get approved
due to a number of Discusses from the other ADs.
There's a number of small details that we can talk about separately, but
I wanted to talk to the working group about the high level issues.
Generally speaking the reviewers
Mark,
ISC's inet_ntop() was released in 1996 as part of BIND 8. It's also in
BIND 9.
Ah, great! Thanks for the information.
Jari
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests:
Pekka, Brian, Juergen,
So, I'd actually suggest that we go for 1) or 2) but soften that a bit,
like: "if it is known by some external method that the prefix includes
an IPv4 address, the representation MAY print it in dotted decimal".
With "external method" I'm thinking of either a
Dan, Seiichi,
Perfect.
Good, but I don't think we're done. I still need more people commenting
on the trade-offs between the different approaches (my mail from Dec
28th). Dan, you commented on the approach #3 and how tool options can
make it more practical. But you didn't explicitly
Seiichi,
I will make the changes. What you pointed out if pretty clear,
and I agree.
Thanks.
Sections 5 and 6 are not as strict with respect to recommending a single
choice as would perhaps be desirable. Is there a reason why the second
alternative in Section 5 can't be removed and the
I have reviewed this draft.
Overall, this is a long overdue change and I want to move forward with
this document. There were a couple of issues I wanted to talk to the
working group before sending the draft to last call, however.
First just an observation. I felt that the motivation part of
specified
in this draft and support adoption by the working group. I was also
unable to find any other RFC or draft that specified the IANA rules
for the routing header Type field.
Regards,
Brian
Jari Arkko wrote:
I spoke about this a little bit in the meeting and got a few
comments. But as far
Alexandru,
I am for adopting this draft as WG document.
Great!
It says that RH types should be allocated through IETF Review or IESG
Approval - these methods seem to me the most appropriated because
offer the widest possible review through IETF - IESG and WG. This is
needed knowing that
registries when I see one. Comments and suggestions would be appreciated.
Jari Arkko wrote:
In the context of reviewing existing IANA registries for various
protocols, we came up with a couple of missing things. The first issue
is that http://www.iana.org/assignments/ipv6-parameters does not point
Brian, Jeffrey,
The picture and text that you quoted are in this RFC exactly as they are
in RFC 4291. We did get some feedback on that text during the last call,
but we decided that it would be confusing for this particular RFC to say
something else than RFC 4291. RFC 4291 is, after all, the
I have reviewed this specification. It is basically in good shape,
though there were a few annoying editorial bugs that I would ask to be
fixed if it weren't for the I-D submissions block at this time. Given
this, I have sent the draft forward for IETF Last Call.
e.g. An IPv6 node ...
For
PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jari Arkko
Sent: Thursday, September 25, 2008 12:02 AM
To: IETF IPv6 Mailing List
Cc: [EMAIL PROTECTED]; V6ops Chairs; Pasi
Eronen; Ron Bonica
Subject: v6ops-addcon and longer than 64 bit prefixes
Folks,
Draft-ietf-v6ops-addcon was in IESG review
Alex,
I agree with what you said, but I wanted to point out one thing:
In a typical IPv6 ADSL household landscape...
An ADSL IPv6 operational deployment offers a /64 prefix at home.
The DSL Forum recommendations for IPv6 are being worked on. I believe
they are based on the concept of
Folks,
Draft-ietf-v6ops-addcon was in IESG review and there was a lot of
discussion about the recommendations an earlier version of the draft had
about prefix lengths longer than 64 bits. The draft has now been revised
to what we believe is reasonably consistent with reality and existing
Marshall,
Several people have indeed indicated desire to participate remotely, and
we are doing everything we can to make that possible.
I think we will at least have a voice stream coming out of the meeting,
jabber scribing (participants, please volunteer to scribe!), and
possibility for
FYI. Registration is now open, and hotel information is on the wiki:
An interim meeting will be organized on October 1 - 2 in Montreal,
Canada to continue discussions about the IPv4 and IPv6 co-existence,
NAT-PT replacement, and new tunneling or translation solutions to
address needs in this
6MAN and V6OPS WGs,
This informational document suggests changes to how
TCP deals with certain classes of ICMP errors. This affects
behavior in a number situations, including what happens
to dual stack nodes when they attempt to connect to hosts
that have both IPv4 and IPv6 addresses.
The
James,
I know of no reason to refer to the old 2023 assignment of 004f.
For the purposes of pointing people to the right spec for implementing
or understanding something, there is no reason to refer to 2023.
For the purposes of knowing which numbers have been allocated, reference
to 2023
Ok.
Jari
James Carlson kirjoitti:
Jari Arkko writes:
I know of no reason to refer to the old 2023 assignment of 004f.
For the purposes of pointing people to the right spec for implementing
or understanding something, there is no reason to refer to 2023.
For the purposes
FYI
The IESG wrote:
The IESG has approved the following document:
- 'Deprecation of Type 0 Routing Headers in IPv6 '
draft-ietf-ipv6-deprecate-rh0-01.txt as a Proposed Standard
This document is the product of the IP Version 6 Working Group.
The IESG contact persons are Jari Arkko
I am fine with the contents of the draft. (As you
may recall the history of this draft, this part got
split off from the IPv6 PPP spec due to DS advancement
issues.)
I agree with the reference and IANA rule suggestions
from James, though.
Jari
Brian Haberman kirjoitti:
All,
This starts a
I did not see any complaints, so given that Brian's new
version is in the directories I will proceed with the
approval.
Thanks,
Jari
Brian Haberman kirjoitti:
All,
The IESG reviewed the RA flags option draft and provided several
comments. In order to address those comments, I proposed
required by our downref
process: The document Updates both RFC 2460
(core IPv6 spec, DS) by removing functionality and
RFC 4294 (IPv6 node requirements, Informational)
while itself being destined for PS.
Jari Arkko
AD for IPv6 WG
I think we had some material in the v6ops security overview
draft:
http://tools.ietf.org/html/draft-ietf-v6ops-security-overview-06#section-2.1.1
but not in too much depth.
Jari
Christopher Morrow kirjoitti:
Is there an existing RFC/Draft discussion of RH0 pitfalls and
solutions to
So I have not heard objections, and I have heard a few
confirmations from the editor, chairs, etc, so we are
moving ahead with this.
Jari
Jari Arkko kirjoitti:
Folks,
The 2461bis document has been for a (long) while in AUTH48. This
is also affecting other documents that are pending
Dow,
- If a consenting nodes only model is adopted, is any arbitrary
behavior by those consenting nodes deemed acceptable by the
non-consenting nodes? Previous discussions seemed to indicate that at
least some folks would answer no to this question.
In other words, how is using RH 253
Chris,
Yup, and someone/no-one noted this as a real concern with ipv6 RH0,
everyone focused on the least interesting problem and decided to
shutdown RHO and excise it from the protocol... a blatant knee jerk
reaction. It's interesting to me that this blatant knee jerk reaction
is getting a
So are you _really_ sure you want to drop RH0 from the IPv6 protocol
spec, given that the practicalities of a general use 'replacement'
header is going to present some fascinating transition issues?
I suspect code changes are necessary in any case, completely
independent of whether RH0 or RHx
Hi Jason,
It relates to a more general
discussion of source routing and feature parity in IPv4 and IPv6. If you
are going to deprecate IPv6 source routing, then you should also deprecate
IPv4 source routing.
For the record, earlier review of the IPv4 source routing RFCs
convinced me at
It works for me, but only in v4. Some routing issue in v6
side. Ccing Henrik who runs these sites.
Jari
David Malone kirjoitti:
On Mon, Aug 20, 2007 at 11:54:29AM +0100, Tim Chown wrote:
(http://tools.ietf.org/html/draft-narten-ipv6-3177bis-48boundary-02)
I note that the IPv6
Hemant,
I have reviewed your draft and the discussion on the IPv6 list.
Its easy to believe that there are implementations out there
that get things wrong. I also agree with the general technical
direction about DAd and being specific about where ND on-link
assumptions and prefixes can come
Also, could the cahirs confirm the final status of the existing eight WG
drafts as listed at:
http://www.ietf.org/html.charters/ipv6-charter.html
Four of these aren't mentioned in the revised charter; are they
expected to complete before 6MAN forms?
http://tools.ietf.org/wg/ipv6/ gives
I also believe that the PMIP capability mechanism is something
that should come out of the discussions in NETLMM. Of course,
the IPv6 experts need to be consulted.
Jari
Suresh Krishnan kirjoitti:
Hi Raj,
Basavaraj Patil wrote:
Hi Brian,
One of the tasks that the 6MAN WG is chartered for is
Alain,
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 the IETF represented by
the AD about what should and
Tim,
I agree that ULA-C needs a home but disagree the IPv6 Maintenance WG is it,
given:
* the first paragraph of the proposed charter:
The sole purpose of this group is in the maintenance of the core
IPv6 protocol specifications and *not* in the development of new
solutions or changes
Is the a document shepherd writeup?
See:
http://www.ietf.org/IESG/content/Doc-Writeup.html
Jari
ext Bob Hinden kirjoitti:
Jari Mark,
On behalf of the IPv6 WG, the chairs request the advancement of
Title : IPv6 Router Advertisement Flags Option
Author(s) : B. Haberman, R. Hinden
Itojun,
I think deprecation of RH0 along with BCP 38/84 ingress filtering on the edge
would be effective in limiting attacks to internal networks.
you know what, too much ingress filtering without rthdr2 support (MIP6
home address option) would kill MIP6 at once. MIP6
Pekka,
Dunno about that, but I guess an Updates: 4294 (IPv6 Node
Requirements) would be in order.
Yes, that would be good.
Jari
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests:
Iljitsch,
With regard to IPv4, ADs seemed to feel that it should be addressed
in a separate document.
Why? Are we going to have separate documents for IPv4 and IPv6 until
the end of time, even if the issues overlap 80%?
I have found that its management-wise easier to deal with small
Iljitsch,
In short: the draft uses undefined terminology, does more than it is
supposed to do, provides no explanation of any kind but rather refers
to an external document that is high on rhetoric
If there is rhetoric, lets get rid of it. Please suggest specific changes.
- the draft
1) Deprecate all usage of RH0
2) Recommend that RH0 support be off by default in hosts and routers
3) Recommend that RH0 support be off by default in hosts
4) Limit it's usage to one RH0 per IPv6 packet and limit the number
of addresses in one RH0.
My preference is 2 or alternatively 1.
Just in case folks are missing out on this, find below a rather nasty
security issue.
I cannot say that this is a big surprise, even if the specific attack
is news to me and it has a major impact. Some issues with Type 0
have been known for years; I think draft-savola-ipv6-rh-ha was the
Hi Fred,
1. What are the issues wrt proxy/relay DAD that would
interfere with its adoption as a standard mechanism?
Almost anything can be made to work, but often
the question is what works best or with least
changes. In particular, we can make proxy DAD
work, probably even with SEND.
We are last calling this document for the second time, for
two reasons. The first reason is to make sure that the
last call has been circulated widely enough in the
community.
The second reason is that we want to call the attention
of the IETF community on the specific issue of using
IPv6
Tim,
Given that there is a historical precedent for being able to do something via
more than one standardized IETF way, I'd suggest that IPv6 PD is another such
case where such an approach is warranted.
...
I'd like to repeat my/our contention that ICMPv6 PD is not meant to replace
DHCPv6 PD.
Also, the subnet model that NetLMM WG wants to choose is to have
a unique prefix for each MN.
Having a unique prefix for each MN is not the same as a
requirement to perform prefix delegation. Netlmm hosts
are required to work with existing stacks, and I would
generally expect them to use
Folks,
Ron has requested publication of his experimental ICMP extension
document which makes it possible to attach options to IPv4 ICMP
messages, mainly the error messages. One background for this
work is the use of such extensions in MPLS networks but other
uses are possible too.
The
They should be updated. By the way I noticed recently
that the RFC Editor does not necessarily do obsoleted by
updates to references automatically. This stuff needs to
be done by the authors in AUTH48. And in this particular
case we have even text changes, as you point out.
By the way, there are
Erik Nordmark wrote:
If there is new functionality in the stack and new piece of
infrastructure, it *may* be possible to provide sufficient
incentives for upgrading the applications. I would imagine that
security might be such a feature in the long run.
But security of what? See
1 - 100 of 150 matches
Mail list logo
