ipv6-wg

Download

ipv6-wg@ripe.net

February 2001

7 participants
11 discussions

Fw: RFC 3041 on Extensions to IPv6 Address Autoconfiguration
by Thomas Trede 02 Feb '01

02 Feb '01

FYI. Regards, Thomas Trede ----- Original Message ----- From: "RFC Editor" <rfc-ed(a)ISI.EDU> To: <IETF-Announce: ;> Cc: <rfc-ed(a)ISI.EDU>; <ipng(a)sunroof.eng.sun.com> Sent: Friday, February 02, 2001 6:11 PM Subject: RFC 3041 on Extensions to IPv6 Address Autoconfiguration > > A new Request for Comments is now available in online RFC libraries. > > > RFC 3041 > > Title: Privacy Extensions for Stateless Address > Autoconfiguration in IPv6 > Author(s): T. Narten, R. Draves > Status: Standards Track > Date: January 2001 > Mailbox: narten(a)raleigh.ibm.com, richdr(a)microsoft.com > Pages: 17 > Characters: 44446 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-ipngwg-addrconf-privacy-04.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3041.txt > > > Nodes use IPv6 stateless address autoconfiguration to generate > addresses without the necessity of a Dynamic Host Configuration > Protocol (DHCP) server. Addresses are formed by combining network > prefixes with an interface identifier. On interfaces that contain > embedded IEEE Identifiers, the interface identifier is typically > derived from it. On other interface types, the interface identifier > is generated through other means, for example, via random number > generation. This document describes an extension to IPv6 stateless > address autoconfiguration for interfaces whose interface identifier is > derived from an IEEE identifier. Use of the extension causes nodes to > generate global-scope addresses from interface identifiers that change > over time, even in cases where the interface contains an embedded IEEE > identifier. Changing the interface identifier (and the global-scope > addresses generated from it) over time makes it more difficult for > eavesdroppers and other information collectors to identify when > different addresses used in different transactions actually correspond > to the same node. > > This document is a product of the IPNG Working Group of the IETF. > > This is now a Proposed Standard Protocol. > > This document specifies an Internet standards track protocol for > the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the > "Internet Official Protocol Standards" (STD 1) for the > standardization state and status of this protocol. Distribution > of this memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST(a)IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST(a)RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info(a)RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info(a)RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager(a)RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution.echo > Submissions for Requests for Comments should be sent to > RFC-EDITOR(a)RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. >

1 0