~andreserl/ubuntu/lucid/bind9/bind9-apport-533601

« back to all changes in this revision

Viewing changes to doc/rfc/rfc4159.txt

  • Committer: Bazaar Package Importer
  • Author(s): LaMont Jones, LaMont Jones, Internet Software Consortium, Inc, localization folks
  • Date: 2008-08-02 14:20:20 UTC
  • mfrom: (1.2.1 upstream) (6.1.24 intrepid)
  • Revision ID: james.westby@ubuntu.com-20080802142020-l1hon9jy8lbbjxmg
[LaMont Jones]

* default to using resolvconf if it is installed
* fix sonames and dependencies.  Closes: #149259, #492418
* Do not build-depend libcap2-dev on non-linux.  Closes: #493392
* drop unused query-loc manpage.  Closes: #492564
* lwresd: Deliver /etc/bind directory.  Closes: #490027
* fix query-source comment in default install

[Internet Software Consortium, Inc]

* 9.5.0-P2.  Closes: #492949

[localization folks]

* l10n: Spanish debconf translation.  Closes: #492425 (Ignacio Mondino)
* l10n: Swedish debconf templates.  Closes: #491369 (Martin Ågren)
* l10n: Japanese debconf translations.  Closes: #492048 (Hideki Yamane
  (Debian-JP))
* l10n: Finnish translation.  Closes: #490630 (Esko Arajärvi)
* l10n: Italian debconf translations.  Closes: #492587 (Alessandro Vietta)

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
 
2
 
 
3
 
 
4
 
 
5
 
 
6
 
 
7
 
Network Working Group                                          G. Huston
8
 
Request for Comments: 4159                                         APNIC
9
 
BCP: 109                                                     August 2005
10
 
Category: Best Current Practice
11
 
 
12
 
 
13
 
                        Deprecation of "ip6.int"
14
 
 
15
 
Status of This Memo
16
 
 
17
 
   This document specifies an Internet Best Current Practices for the
18
 
   Internet Community, and requests discussion and suggestions for
19
 
   improvements.  Distribution of this memo is unlimited.
20
 
 
21
 
Copyright Notice
22
 
 
23
 
   Copyright (C) The Internet Society (2005).
24
 
 
25
 
Abstract
26
 
 
27
 
   This document advises of the deprecation of the use of "ip6.int" for
28
 
   Standards Conformant IPv6 implementations.
29
 
 
30
 
1.  IPv6 Standards Action
31
 
 
32
 
   In August 2001 the IETF published [RFC3152], which advised that the
33
 
   use of "ip6.int" as the domain for reverse-mapping of IPv6 addresses
34
 
   to DNS names was deprecated.  The document noted that the use of
35
 
   "ip6.int" would be phased out in an orderly fashion.
36
 
 
37
 
   As of 1 September 2005, the IETF advises the community that the DNS
38
 
   domain "ip6.int" should no longer be used to perform reverse mapping
39
 
   of IPv6 addresses to domain names, and that the domain "ip6.arpa"
40
 
   should be used henceforth, in accordance with the IANA Considerations
41
 
   described in [RFC3596].  The domain "ip6.int" is deprecated, and its
42
 
   use in IPv6 implementations that conform to the IPv6 Internet
43
 
   Standards is discontinued.
44
 
 
45
 
   The Regional Internet Registries (RIRs) are advised that maintenance
46
 
   of delegation of entries in "ip6.int" is no longer required as part
47
 
   of infrastructure services in support of Internet Standards
48
 
   Conformant IPv6 implementations as of 1 September 2005.  The RIRs are
49
 
   requested to work with their communities to adopt a schedule
50
 
   regarding the cessation of support of registration services for the
51
 
   "ip6.int" domain.
52
 
 
53
 
 
54
 
 
55
 
 
56
 
 
57
 
 
58
 
Huston                   Best Current Practice                  [Page 1]
59
 
 
60
 
RFC 4159                        ip6.int                      August 2005
61
 
 
62
 
 
63
 
2.  IANA Considerations
64
 
 
65
 
   IANA is advised that the "ip6.int" domain for reverse mapping of IPv6
66
 
   addresses to domain names is no longer part of Internet Standards
67
 
   Conformant support of IPv6 as of 1 September 2005.
68
 
 
69
 
3.  Security Considerations
70
 
 
71
 
   While DNS spoofing of address to name mapping has been exploited in
72
 
   IPv4, removal of the "ip6.int" zone from the standard IPv6
73
 
   specification creates no new threats to the security of the internet.
74
 
 
75
 
4.  Acknowledgements
76
 
 
77
 
   The document was prepared with the assistance of Kurt Lindqvist,
78
 
   Thomas Narten, Paul Wilson, David Kessens, Bob Hinden, Brian
79
 
   Haberman, and Bill Manning.
80
 
 
81
 
5.  Normative References
82
 
 
83
 
   [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
84
 
             August 2001.
85
 
 
86
 
   [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
87
 
             Extensions to Support IP Version 6", RFC 3596, October
88
 
             2003.
89
 
 
90
 
Author's Address
91
 
 
92
 
   Geoff Huston
93
 
   APNIC
94
 
 
95
 
   EMail: gih@apnic.net
96
 
 
97
 
 
98
 
 
99
 
 
100
 
 
101
 
 
102
 
 
103
 
 
104
 
 
105
 
 
106
 
 
107
 
 
108
 
 
109
 
 
110
 
 
111
 
 
112
 
 
113
 
 
114
 
Huston                   Best Current Practice                  [Page 2]
115
 
 
116
 
RFC 4159                        ip6.int                      August 2005
117
 
 
118
 
 
119
 
Full Copyright Statement
120
 
 
121
 
   Copyright (C) The Internet Society (2005).
122
 
 
123
 
   This document is subject to the rights, licenses and restrictions
124
 
   contained in BCP 78, and except as set forth therein, the authors
125
 
   retain all their rights.
126
 
 
127
 
   This document and the information contained herein are provided on an
128
 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
129
 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
130
 
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
131
 
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
132
 
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
133
 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
134
 
 
135
 
Intellectual Property
136
 
 
137
 
   The IETF takes no position regarding the validity or scope of any
138
 
   Intellectual Property Rights or other rights that might be claimed to
139
 
   pertain to the implementation or use of the technology described in
140
 
   this document or the extent to which any license under such rights
141
 
   might or might not be available; nor does it represent that it has
142
 
   made any independent effort to identify any such rights.  Information
143
 
   on the procedures with respect to rights in RFC documents can be
144
 
   found in BCP 78 and BCP 79.
145
 
 
146
 
   Copies of IPR disclosures made to the IETF Secretariat and any
147
 
   assurances of licenses to be made available, or the result of an
148
 
   attempt made to obtain a general license or permission for the use of
149
 
   such proprietary rights by implementers or users of this
150
 
   specification can be obtained from the IETF on-line IPR repository at
151
 
   http://www.ietf.org/ipr.
152
 
 
153
 
   The IETF invites any interested party to bring to its attention any
154
 
   copyrights, patents or patent applications, or other proprietary
155
 
   rights that may cover technology that may be required to implement
156
 
   this standard.  Please address the information to the IETF at ietf-
157
 
   ipr@ietf.org.
158
 
 
159
 
Acknowledgement
160
 
 
161
 
   Funding for the RFC Editor function is currently provided by the
162
 
   Internet Society.
163
 
 
164
 
 
165
 
 
166
 
 
167
 
 
168
 
 
169
 
 
170
 
Huston                   Best Current Practice                  [Page 3]
171