Hi all,
There has been some discussions whether or not we should add support for the
Flow Label in
Soon to be RFC 6434 draft-ietf-6man-node-req-bis-11.txt As a straw man
proposal, if we add
Support, I would suggest the following text:
All nodes SHOULD support RFC 6437, IPv6 Flow Label
Dumb question, but isn't the text making support for DHCPv6 a SHOULD, but not
making it a SHOULD or MUST to run?
I completely agree that in some networks (or interfaces) where the node 'knows'
that DHCP isn't deployed in the network, there is no sense in running DHCP.
-Original
Hi all,
In general, I support Thomas' text, but I still think some clarification is
needed:
New:
t DHCPv6 xref target='RFC3315' / can be used to obtain and
configure addresses. In general, a network may provide for the
configuration of addresses through Router
Tim,
I think we are talking about the need of supporting DHCPv6, not the use of
DHCPv6. Nodes that are in a SOHO environment may not need to use DHCPv6, but if
those nodes also move outside of the SOHO network, they might need DHCPv6 in
other networks. IMO, the ability to support both DHCPv6
Hi Ralph,
I think the IETF has been pretty good about keeping the information from the
two sources independent. Regarding address assignment specifically, what
contradictory information might be provided? I can imagine a node might get
one address from SLAAC and another from DHCPv6, but
I also think that dealing with this issue in more detail may not be so easy,
and it would be better to do that as updates to those documents (or a
standalone
document).
E.g., even DHCP by itself has a longstanding vagueness about how to handle
the merging of information received from
Thomas,
One small comment and one small nit, inline:
* 5.9.4 Default Address Selection
As RFC3484 generates IPv6 brokenness. I think we should change
this reference to RFC3484bis.
Can't do that. That would delay publication of the RFC.
BTW, you could make the same arguement w.r.t.
I agree with Bob. Also, the world is a bit different than in 1989 and 1995.
There are a lot of organizations creating different IPv6 'profiles',
'certifications' and guidelines. I think it has always been our intention to
use the Node Requirements to provide some guidelines from the IETF
I agree with Brian on both points.
-Original Message-
From: ext Brian E Carpenter
Sent: 02/18/2011, 11:34 AM
To: Pekka Savola
Cc: Thomas Narten; 6man Mailing List
Subject: Re: 6MAN WG Last Call: draft-ietf-6man-node-req-bis-07.txt
On 2011-02-18 21:55, Pekka Savola wrote:
...
I think
Brian,
I did not see any comments on this, but in general I agree with your points
below.
Comments in-line
-Original Message-
I would be happy to see this published as-is, but I did notice
a few points.
I think the Introduction needs a general warning something like:
This
To reply to Julian's mail. I think the issue is more about deployments rather
than devices. I know plenty of low-powered devices that have successfully
implemented
/ deployed IPsec, when needed. However, I think the real issue is that in many
circumstances, people feel that deployment specific
Thomas,
I don't think that client / server functionality are so well defined in most of
the IPv6 RFCs, but are more of the node / router functional split. I think
giving some additional information about how a particular node is used is good
- but at the end of the day, most of the node
I would support Applicability Statement status as that would give us more room
to make some recommendations on specifications outside of the core set of IPv6
standards. If you look at what Tim is asking for MLDv2, others are asking for
SeND/CGA, etc. - I think it makes a lot of sense ot have a
Hesham,
I agree with you, the Node cannot know this, it can only do the right thing
once the SeND process starts. Do people feel that SeND should be a basic
feature of IPv6 that all nodes SHOULD support?
John
-Original Message-
From: ipv6-boun...@ietf.org
Hi,
Is LW-MLDv2 a profile of MLDv2 or a subset? Does it update or modify
the MLDv2 specs? I'm somewhat confused about the relationship between
them.
thanks,
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of ext Hitoshi Asaeda
Sent: 20 November, 2008
Hi Pekka,
On Fri, 14 Nov 2008, Daniel Park wrote:
I would make a minor change according to the valuable comments from
the WiMAX expert:
There are two ways to transfer IPv6 over WiMAX:
- IPv6 over WiMAX using IPCS: RFC5121
- IPv6 over Ethernet carried over WiMAX: AD Evaluation (ID Status)
I agree with you and with James, so I will reject this issue - no
changes needed.
John
-Original Message-
From: ext Brian Haberman [mailto:[EMAIL PROTECTED]
Sent: 13 November, 2008 18:06
To: Loughney John (Nokia-D/MtView)
Cc: ipv6@ietf.org
Subject: Re: Node Requirement: New issue 5:
Daniel,
Could you explain what the IPCS abbreviation stands for?
thanks,
John
From: ext Daniel Park [mailto:[EMAIL PROTECTED]
Sent: 14 November, 2008 01:20
To: Loughney John (Nokia-D/MtView)
Cc: ipv6@ietf.org
Subject:
Thanks. This seems like a reasonable addition.
John
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of ext Basavaraj Patil
Sent: 14 November, 2008 15:30
To: Loughney John (Nokia-D/MtView); Daniel Soohong Park
Cc:
I recieved a question:
What about RFC5006 Router Advertisement Option for DNS Configuration,
or is it problem that it is of experimental category?
My feeling is that this is experimental, so it cannot really be a
requirement.
What does the working group think?
Daniel Park sent this issue in:
I'd request one more requirement for this bis. It is about 16ng
deliverable for IPv6 transmission over IPv6CS networks as RFC 5121. Due
to Convergence Sublayer characteristics of WiMAX networks, the below
requirement must be included in the Node Requirement. (For
This seems like a good reference to add:
section 5.1, last paragraph. Shouldn't the doc reference RFC 5095 and
deprecation of RH0? suggest:
An IPv6 node MUST be able to process these headers. An exception is
Routing Header type 0 (RH0) which is deprecated by [RFC 5095] due to
security concerns,
Hi all,
The RFC 4294-bis draft has the following requirement, which comes from
the initial RFC.
8.1. Basic Architecture
Security Architecture for the Internet Protocol [RFC-4301] MUST be
supported.
8.2. Security Protocols
ESP [RFC-4303] MUST be supported. AH [RFC-4302] MUST be
Sorry, that was a cut paste mistake. AH is a MAY.
John
-Original Message-
From: ext Vishwas Manral [mailto:[EMAIL PROTECTED]
Sent: 05 March, 2008 12:12
To: Loughney John (Nokia-OCTO/PaloAlto)
Cc: ipv6@ietf.org
Subject: Re: Security Requirements for IPv6 Node Req summary
Hi John,
Kevin,
I would say that is not a logical argument, IMO. The IETF
has long considered security to be an essential part of internet
protocols. Pease read http://tools.ietf.org/html/rfc4301.
SMTP in that sense is optional, and not considered a part
of IPv6. The ability to secure the IP layer has
James,
Ed Jankiewicz writes:
As Jim Bound has stated many times, IETF defines standards not
deployment, and the Node Requirements revision should reiterate that
the standard for security in IPv6 is IPsec citing RFC 4301
(successor
to 2401). OTOH, we at DoD and NIST are certainly
My fear is that if implementations on e.g. sensors show that
IPSec is not affordable for this kind of device, and we put an
unconditional MUST, in a few years from now we will have
billions of device which do not respect RFC4294. With a SHOULD
it is the same kind of issue, billions of device
Hi all,
If people feel that further disclaimers are needed in the current bis
draft
to ensure that people understand that it only meant as an informative
compendium, then I am happy to add that extra text.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Thomas,
As a general node requirement, SHOULD is the right level, not MUST.
I veer to being somewhat conservative in this area. I don't think that
we should be
re-interpreting Standards-track RFCs in the Node Req document. I think
that we can only refer
to what the base standards track RFCs
Julien and Alain,
My high-level question to you both is, for sensors and set-top
boxes - do you feel that you do not need security for any
reason? Is this a long-term issue or a short-term issue.
I can't really think of a reason why security would not be an
issue, but I could be wrong.
John
Julien,
I guess the point is that some cases and deployment, secuirty is not required
to be used.
However, if you are making a product and you do not include security as part of
the solution,
than IPSec then you have a problem.
John
Fine with this
The important point as Kevin Kargel
Julien,
Ok, I get it, but I would think this is to be left to the
choice of the vendor if/how he provides security.
I am in favor of the approach where node requirements rfc
defines the bare minimum for two nodes to be able to talk to
each other, then phrase the other sections like setion
Jeremy,
Is there also anyway the new node requirements RFC could be
somewhat reconciled with the new US Government IPv6 Profile
and the DoD IPv6 Profile?
It would probably keep the confusion down a bit.
Would you be able to provide a summary of the differences? Also,
are the US Government
Hi Ed,
That would be great. If the comparison is useful, we can then include
it as an appendix or at least discuss some of the differences.
thanks,
John
-Original Message-
From: ext Ed Jankiewicz [mailto:[EMAIL PROTECTED]
Sent: 25 February, 2008 10:21
To: ipv6@ietf.org
Cc: Duncan,
Hi all,
I am issuing a quick rev to the Node Req.-bis. There are a couple of
bugs, with respect to the references, that I need to fix still, but I
switched to using Symbolic References, and added a quick dirty list of
changes from RFC4294.
One question, I assume that I should include
Hi Brian,
I will fix the references, I had some issues with them when converting
from
nroff to xml. I have the fix. I will also create a list of changes as
well,
that is a good point.
John
-Original Message-
From: ext Brian E Carpenter [mailto:[EMAIL PROTECTED]
Sent: 21 February,
Hi all,
I have updated this draft. I had to wrestle with the nroff to get it
into xml. I spent
too much time with that, so I ended up mostly updating the references
and fixing the errata.
I have not done to much editorial control, checking on what has changed
on the many RFC
updates since this
Hi Ed,
I will try to get an initial version out shortly. I am happy to have
some help, so let's exchange some mails off-list.
John
-Original Message-
From: ext Ed Jankiewicz [mailto:[EMAIL PROTECTED]
Sent: 21 January, 2008 06:29
To: ipv6@ietf.org
Subject: RFC 4294 Update
Consensus
Brian,
The 6MAN agenda for Vancouver has been updated. Please notice
that we will be *very* tight on time and the chairs will hold
presenters to there time allotment.
I completely messed my schedule up, and had to leave last night, so I
cannot
make the meeting today. I tried to find
Hi Thomas,
Thanks for your comments. Speaking as an individual (not document
author) this is what I think is the right way forward, but I wanted
to make sure that this would be useful for the WG.
John
-Original Message-
From: ext Thomas Narten [mailto:[EMAIL PROTECTED]
Sent: 05
Suresh,
Check that my comments are refering to the right text, the formatting
is off on your mail, so I had a hard time parsing some of your comments.
For many of the MAYs, my opinion is that if we don't say anything about
it,
people will ask if these features are required or not. I think this
James
Kempf sent this mail to the IPv6 mailing list in May.
John
L.
DoCoMo Labs USA has finally released its OpenSource
implementation of RFC 3971, 3972, and 3779 for SEcure Neighbor Discovery (SEND).
The code and documentation can be downloaded at:
Gentlemen,
It would seem a fairly simple yet worthwhile thing to standardize the
endianness of IPv6 (both headers and payload for that matter).
Is it the majority view that we should do this?
I'm in favor. It's certainly a better use of the IETF's
collective time than all the process
Hi Bob,
How important is this? I didn't make the meeting at the last IETF
meeting, but in Vancouver, it didn't seem like they were planning any
big work items.
It's another IPv6 over foo effort. What makes this one more
complicated is it's not just another Ethernet compatible
network.
Hi Daniel,
Thanks for the info, you're right that I hadn't see this. I'll look
through
the procedings now.
thanks,
John
-Original Message-
From: ext Soohong Daniel Park [mailto:[EMAIL PROTECTED]
Sent: 03 May, 2006 09:37
To: Hinden Bob (Nokia-ES/MtView); Loughney John
How important is this? I didn't make the meeting at the last IETF
meeting, but
in Vancouver, it didn't seem like they were planning any big work items.
John
-Original Message-
From: ext Bob Hinden [mailto:[EMAIL PROTECTED]
Sent: 03 May, 2006 01:26
To: IPv6 WG
Subject: Fwd: WG Review: IP
I know this is too late but why wern't the changes from the
thread
http://www1.ietf.org/mail-archive/web/ipv6/current/msg01689.html
incorporated?
Looks like I missed that during AUTH48. Want to file an erratta about
it?
My guess is that at some point, we'll need to make a
47 matches
Mail list logo
