Chad,
Why would you want a specific range? To reduce the (small)
risk from scanning attacks, a unique pseudo-random choice would be
better, IMHO, as long as it conforms to RFC 4291 and 5453.
BTW this question might fit better on the v6ops list or even
on ipv6-...@lists.cluenet.de where there are
Hi Thomas,
The most recent version of the
Basic Requirements for IPv6 Customer Edge Routers
draft is utilising RFC4191 Route Information Options to propagate
routing information to end-nodes for the internal network. I was
wondering if support for those should now be included in this revisio
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 : An uniform format for IPv6 extension headers
Author(s) : S. Krishnan, et al.
Filename
Hello,
We are deploying IPV6 to our customers and are carefully planning the
architecture of how we are going to deploy prefixes, assign customer gateways
and how we are going to number our own infrastructure in a meaningful way.
Although I think Stateless Autoconfiguration will be used quite
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 sh
Would you like an abstracted test report to the reflector instead?
Don
Bob Hinden wrote:
>Thomas,
>
>On Dec 17, 2010, at 4:41 AM, Thomas Narten wrote:
>
>> Fred Baker writes:
>>
>>> When we advance a routing protocol to Proposed Standard, for reasons
>>> related to ancient IESG history relate
The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'Using 127-bit IPv6 Prefixes on Inter-Router Links '
as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please s
Fred,
> The fact is that the working group is trying to decide n something and Zigbee
> has relevant data. I'm simply asking for an appropriately-redacted version of
> the report to be made public.
Sharing implementation experience is always good thing to assist a w.g. to make
a decision on ad
Thomas,
On Dec 17, 2010, at 4:41 AM, Thomas Narten wrote:
> Fred Baker writes:
>
>> When we advance a routing protocol to Proposed Standard, for reasons
>> related to ancient IESG history related to routing, we generally
>> require a test report that shows interoperable implementations of
>> th
> The fact is that the working group is trying to decide n something
> and Zigbee has relevant data. I'm simply asking for an
> appropriately-redacted version of the report to be made public.
Works for me. I just didn't want anyone to think this was a IETF
*requirement*.
Thomas
On Dec 17, 2010, at 4:41 AM, Thomas Narten wrote:
> Fred Baker writes:
>
>> When we advance a routing protocol to Proposed Standard, for reasons
>> related to ancient IESG history related to routing, we generally
>> require a test report that shows interoperable implementations of
>> the standa
Fred Baker writes:
> When we advance a routing protocol to Proposed Standard, for reasons
> related to ancient IESG history related to routing, we generally
> require a test report that shows interoperable implementations of
> the standard in question.
And FWIW, I think that requirement expir
12 matches
Mail list logo
