On 2-aug-2005, at 15:41, Tony Hain wrote:
I choose not to try to get to the mic, but on the debated
requirement point
3; why is there a belief that the DHCP relay information is correctly
configured if the simpler set of 2 bits is improperly configured?
I think a case can be made for the
On Tue, Aug 02, 2005 at 06:49:50PM +0100, Tim Chown wrote:
Hi,
I raised this question today but we were short of time.
My concern is that in an enterprise deployment, I might want to avoid the
complexity of privacy addresses (from the management perspective).
Right, I'm not sure if that
On Aug 2, 2005, at 5:27 PM, JINMEI Tatuya / 神明達哉 wrote:
At the
very bottom line, my understanding is that we can accept some level of
extensions to the current protocol...is that correct?
Yes, I think that's correct. The one extension I heard proposed,
which made stateless DHCP more
Hi Ron,
On Tue, 2 Aug 2005 15:10:53 -0500
Pashby, Ronald W CTR NSWCDD-B35 [EMAIL PROTECTED] wrote:
Greg, et. al,
You stated:
Regarding draft-pashby-ipv6-network-discovery-00.txt,
this provides a mechanism for devices to be made respond
to queries from another device on the IPv6
In your previous mail you wrote:
In a managed DHC environment, privacy addresses can be returned by DHCPv6
for client use, but my reading of RFC3315 suggests (section 12) that the
request is client initiated, which implies there should/could be some policy
that could be distributed
Erik Nordmark wrote:
I think that might be a reasonable middle ground. It would still make it
harder than in IPv4 to explore all hosts, yet one can have e.g. SNMP
access to a local agent on the link that provide this (with appropriate
SNMP security) to allow remote management.
Elsewhere
Hello All,
Is Final Destination Option (just before upper layer protocol), mutable or immutable?Can
I assume that Destination Options inside AH (before AH) are mutable and
Destination Option outside AH (after AH) as Immutable?
Thanks in advance,
Srinivas.
On Tue, Aug 02, 2005 at 11:20:11PM +0200, Iljitsch van Beijnum wrote:
On 2-aug-2005, at 15:41, Tony Hain wrote:
I choose not to try to get to the mic, but on the debated
requirement point
3; why is there a belief that the DHCP relay information is correctly
configured if the simpler set
Only if they respond to the multicast echo request.
Reality check: by default, host firewalls drop incoming echo requests.
An explicit design goal of these firewalls is to make the host
stealthy, i.e. make sure the host is only detected by parties with
which the host decide to communicate.
I
On 2-aug-2005, at 17:15, Soohong Daniel Park wrote:
2) Other requirements to be considered ?
As someone who gets called when the day-to-day admins can't figure it
out, I feel it's important that all of this is as predictable as
possible. That means that I want to know whether hosts are
I choose not to try to get to the mic, but on the debated
requirement point
3; why is there a belief that the DHCP relay information is correctly
configured if the simpler set of 2 bits is improperly configured?
I think a case can be made for the notion that most routers and most
All,
As mentioned during the IPv6 WG meeting, the chairs are soliciting
implementation reports for IPv6 Privacy Addresses in support of moving
the spec
to Draft Standard. The following template should be used for submitting
these implementation reports. The reports can be sent to the
below
Tom Petch
- Original Message -
From: Eric Klein [EMAIL PROTECTED]
To: ipv6@ietf.org
Sent: Wednesday, August 03, 2005 9:36 AM
Subject: Re: network/all-host discovery and flooding attacks.
Erik Nordmark wrote:
I think that might be a reasonable middle ground. It would still make
Eric Klein wrote:
I agree that the security issues here are great, and that there is a need in
the Management world for this feature. If you could limit this to an SNMP v3
secure function and not a IPv6 function then maybe we could work this out
within the security concerns of all involved. But
Tom Petch wrote:
I think that might be a reasonable middle ground. It would still make
it
harder than in IPv4 to explore all hosts, yet one can have e.g. SNMP
access to a local agent on the link that provide this (with
appropriate
SNMP security) to allow remote management.
On 3-aug-2005, at 10:59, Syam Madanapalli wrote:
I think a case can be made for the notion that most routers and most
networks don't implement the bits today, so seeing MO==00 doesn't
really authoratively say there is no DHCP service, but just that the
routers operate in a default
Hi Folks,
I think the node requirements document needs to be advanced as well
before we should move the base specs to Full Standard as one cannot easily
figure out what she/he should do to be IPv6 compliant. e.g. If I implement
just RFC2460 and not RFC2461 and RFC2462 am I still compliant?
Erik Nordmark wrote:
I agree that the security issues here are great, and that there is a
need in
the Management world for this feature. If you could limit this to an
SNMP v3
secure function and not a IPv6 function then maybe we could work this
out
within the security concerns of all
Hi Suresh,
On Aug 3, 2005, at 6:33, Suresh Krishnan wrote:
Hi Folks,
I think the node requirements document needs to be advanced as well
before we should move the base specs to Full Standard as one cannot
easily figure out what she/he should do to be IPv6 compliant. e.g. If
I implement
Hi Folks,
I think the node requirements document needs to be advanced as well
before we should move the base specs to Full Standard as one cannot
easily figure out what she/he should do to be IPv6 compliant. e.g. If I
implement just RFC2460 and not RFC2461 and RFC2462 am I still compliant?
The Node Requirements is informative, so it doesn't advance. However,
the document should be reved as appropriate to handle the issues you
mention.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
ext Suresh Krishnan
Sent: 03 August, 2005 13:34
Suresh Krishnan wrote:
Hi Folks,
I think the node requirements document needs to be advanced as well
before we should move the base specs to Full Standard as one cannot
easily figure out what she/he should do to be IPv6 compliant. e.g. If I
implement just RFC2460 and not RFC2461 and RFC2462
There was also some question in the past of what to do when the M and
O bits *change* between router advertisements. I can't remember who
brought it up. I don't recall seeing any resolution to this.
While secure RA sounds really neat, I suspect it will not be widely
usable on networks
Following up on the meeting session:
As the IPv6 working group draws to a close the *only* proper action is to
recommend to the IESG that all stable and eligible documents be progressed
along the standards track. The IESG will do whatever it would anyway, so it
does no good to try to fineness
Iljitsch van Beijnum wrote:
On 2-aug-2005, at 17:15, Soohong Daniel Park wrote:
2) Other requirements to be considered ?
As someone who gets called when the day-to-day admins can't figure it
out, I feel it's important that all of this is as predictable as
possible. That means that I
As the IPv6 working group draws to a close the *only* proper action is to
recommend to the IESG that all stable and eligible documents be progressed
along the standards track. The IESG will do whatever it would anyway, so it
does no good to try to fineness things by endless debates about last
This is the charter of the v6ops WG.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Greg Daley
Sent: Tuesday, August 02, 2005 5:56 PM
To: ipv6@ietf.org
Subject: How ready is IPv6 - do we need to describe it?
Hi,
I was chatting with Keith
In your previous mail you wrote:
I think the node requirements document needs to be advanced as well
before we should move the base specs to Full Standard as one cannot easily
figure out what she/he should do to be IPv6 compliant. e.g. If I implement
just RFC2460 and not
DoD would find this information helpful.
Thanks,
Shawn Smith
INTEROP/JITC
Ft. Huachuca, AZ
520-538-5220
-Original Message-
From: Tony Hain
To: 'Greg Daley'; ipv6@ietf.org
Cc: 'Fred Baker'
Sent: 8/3/2005 6:04 AM
Subject: RE: How ready is IPv6 - do we need to describe it?
This is the
Tony, you said it all, and I for one have no more to say on this and we
should take your mail to heart and do exactly what you state.
Regarding making statements about deployment all the IETF can do is make
a statement of implementation state. Further on that mission is in
process in the market
One assumption that is being made is that all hosts are trying to communicate
through a router. There are many networks that hosts only talk to each other.
Looking at ND tables or flows in a router is not viable for these networks.
True network discovery like security, relies on multiple
Ronald Pashby wrote
One assumption that is being made is that all hosts are trying to
communicate through a
router. There are many networks that hosts only talk to each other.
Looking at ND tables or
flows in a router is not viable for these networks.
This is a good point, just look at the
On Wed, 3 Aug 2005 13:10:38 +0530,
Srinivas Goud [EMAIL PROTECTED] said:
Is Final Destination Option (just before upper layer protocol), mutable or
immutable?
Whether an destination (or hop-by-hop) option is mutable is defined
per-option basis. It is irrelevant from the position of the
I do agree with your points, but if you loot at rfc3775, it says that
The use of IPsec Authentication Header (AH) for the Home Address option
is not required, except that if the IPv6 header of a packet is covered
by AH, then the authentication MUST also cover the Home Address option;
this
Hi,
I have question
regarding IPv6auto service discovery.
Suppose a IPv6
Mobile Host comes and joins a network. Using Stateful or Stateless Address
Configuration mentioned in ICMPv6 Router Advertisement message it gets a
IPv6 address.
Butif
themobile host want to know the nearest printer
Hi Abhijit,
I don't know all that much about how it operates however, I think that
is what SLP - Service Location Protocol is designed for. From RFC2608
-
The Service Location Protocol provides a scalable framework for the
discovery and selection of network services. Using this protocol,
36 matches
Mail list logo
