/
558.txt
143 lines (108 loc) · 5.49 KB
/
558.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
[1] [DFN[IP [RUBYB[アドレス]@en[address]]]]は、[[IP]] において通信の当事者を[[識別]]する[RUBY[[[番地]]]@en[アドレス]]です。
[2] [[アドレス]]の体系は [[IP]] の版により異なります。現在利用されているものとしては
[FIG(list short)[
- [[IPv4アドレス]]
- [[IPv6アドレス]]
]FIG]
... の2種類があります。
* 仕様書
[REFS[
- [8] [CITE[[[BR]]]] ([TIME[2014-11-01 05:54:38 +09:00]] 版) <https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf#page=17>
]REFS]
* 名称
[15] [[IPアドレス]]のことを俗に [DFN[[[IP]]]] と言うこともあります。
* 分類
[FIG(short list)[
- [[予約IPアドレス]]
]FIG]
* 文脈
[11] 次の場面では、 [[IPv4アドレス]]はそのまま表記し、
[[IPv6アドレス]]は [...] で括ります。
[FIG(list middle)[
- [[ホストとポート]]
- [[節点識別子]]
- [CODE[[[domainpart]]]]
- [89] [[CGI]] [CODE(CGI)@en[[[SERVER_NAME]]]]
]FIG]
[12] 次の場面では、 [[IPv4アドレス]]はそのまま表記し、
[[IPv6アドレス]]は [IPv6:...] で括ります。
[FIG(middle list)[
- [87] [[SMTP]] ([[メールアドレス]])
]FIG]
[13] 次の場面では、[[IPv4アドレス]]も[[IPv6アドレス]]もそのまま表記します。
[FIG(middle list)[
- [88] [[CGI]] [CODE(CGI)@en[[[REMOTE_ADDR]]]]
- [CODE(JS)@en[[[document.domain]]]]
- [CODE[[[iPAddress]]]]
- [CODE[[[CN]]]]
- [CODE[AnyEvent::Socket]] の入出力
]FIG]
[16] 次のものは、バイト表現を使います。
[FIG(list middle)[
- [CODE[gethostbyname]] の出力
- [[SOCKS4]] の宛先
- [[SOCKS5]] の宛先
]FIG]
[17] バイト表現は、 [[IPv4アドレス]]なら4バイト、[[IPv6アドレス]]なら16バイトで、
[[ネットワークバイト順]]でそのままアドレスを表現したものです。
* FQDN との関係
[4] [[IAB]] は、人間が編集する設定ファイルなどの非揮発性ストレージ上の情報においては、
[[IPアドレス]]よりも [[FQDN]] を使うことを[RUBYB[強く推奨]@en[strongly recommend]]しています。
;; [CITE@en[RFC 1900 - Renumbering Needs Work]]
<http://tools.ietf.org/html/rfc1900#section-3>
* [CODE[iPAddress]] (PKI)
[10] [[BR]] に従う [[CA]] が発行する[[証明書]]の [[SAN]] [CODE[[[iPAddress]]]]
欄での[[予約IPアドレス]]の使用は2016年10月1日までに全廃することになっています [SRC[>>8]]。
* メモ
[3] [[IPアドレス]]は、俗に略して「[[IP]]」と呼ばれることがあります。
[FIG(quote)[
[FIGCAPTION[
[5] [CITE@en[RFC 2459 - Internet X.509 Public Key Infrastructure Certificate and CRL Profile]]
([TIME[2014-12-22 14:13:43 +09:00]] 版)
<http://tools.ietf.org/html/rfc2459#section-4.2.1.7>
]FIGCAPTION]
> When the subjectAltName extension contains a iPAddress, the address MUST be stored in the octet string in "network byte order," as specified in RFC 791 '''['''RFC 791''']'''. The least significant bit (LSB) of each octet is the LSB of the corresponding byte in the network address. For IP Version 4, as specified in RFC 791, the octet string MUST contain exactly four octets. For IP Version 6, as specified in RFC 1883, the octet string MUST contain exactly sixteen octets '''['''RFC 1883''']'''.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[6] [CITE@en[RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile]]
([TIME[2015-02-22 15:44:10 +09:00]] 版)
<http://tools.ietf.org/html/rfc5280#section-4.2.1.6>
]FIGCAPTION]
> When the subjectAltName extension contains an iPAddress, the address
> MUST be stored in the octet string in "network byte order", as
> specified in '''['''RFC791''']'''. The least significant bit (LSB) of each octet
> is the LSB of the corresponding byte in the network address. For IP
> version 4, as specified in '''['''RFC791''']''', the octet string MUST contain
> exactly four octets. For IP version 6, as specified in
> '''['''RFC2460''']''', the octet string MUST contain exactly sixteen octets.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[7] [CITE@en[RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile]]
([TIME[2015-02-22 15:44:10 +09:00]] 版)
<http://tools.ietf.org/html/rfc5280#section-4.2.1.10>
]FIGCAPTION]
> The syntax of iPAddress MUST be as described in Section 4.2.1.6 with
> the following additions specifically for name constraints. For IPv4
> addresses, the iPAddress field of GeneralName MUST contain eight (8)
> octets, encoded in the style of RFC 4632 (CIDR) to represent an
> address range '''['''RFC4632''']'''. For IPv6 addresses, the iPAddress field
> MUST contain 32 octets similarly encoded. For example, a name
> constraint for "class C" subnet 192.0.2.0 is represented as the
> octets C0 00 02 00 FF FF FF 00, representing the CIDR notation
> 192.0.2.0/24 (mask 255.255.255.0).
>
]FIG]
[9] [CITE@en[draft-main-ipaddr-text-rep-02 - Textual Representation of IPv4 and IPv6 Addresses]]
([TIME[2015-04-24 04:28:53 +09:00]] 版)
<https://tools.ietf.org/html/draft-main-ipaddr-text-rep-02>
[FIG(quote)[
[FIGCAPTION[
[14] [CITE@en[RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1]]
([TIME[2015-07-11 23:51:35 +09:00]] 版)
<http://tools.ietf.org/html/rfc2616#section-3.2.2>
]FIGCAPTION]
> The use of IP addresses
> in URLs SHOULD be avoided whenever possible (see RFC 1900 '''['''24''']''').
]FIG]