I got a late read on this draft, and may find some editorial nits:
#1. In sec. 3,
" End-user IPv6 prefix: The IPv6 prefix assigned to an End-user CE by
other means than MAP itself. E.g.,
Provisioned using DHCPv6 PD [RFC3633],
assigned via SLAAC [RFC4862], or configured
manually. It is unique for each CE. "
Q. Does the above means ' End-user IPv6 prefix ' includes 's bits' (the
subnet ID) in Fig.3?
But in sec. 5.2,
" The MAP IPv6 address is created by concatenating the End-user IPv6
prefix with the MAP subnet identifier (if the End-user IPv6 prefix is
shorter than 64 bits) and the interface identifier as specified in
Section 6. "
Q. Does the above means ' End-user IPv6 prefix ' does not include 's bits'
(the subnet ID) in Fig.3? I guess we could include 's bits' (the subnet ID=
MAP subnet identifier) into ' End-user IPv6 prefix '.
And in sec. 6,
" If the End-user IPv6 prefix length is larger than 64, the most
significant parts of the interface identifier is overwritten by the
prefix. "
Q. Does the above means ' End-user IPv6 prefix ' includes 's bits' (the
subnet ID) in Fig.3?
#2. In sec. 5.1,
" For 'a' > 0, A MUST be
larger than 0. This ensures that the algorithm excludes the
system ports. For the default value of a (6), the system ports,
are excluded by requiring that A be greater than 0. Smaller
values of a excludes a larger initial range. E.g., a = 4, will
exclude ports 0 - 4095. The interval between initiaL port numbers
of successive contiguous ranges assigned to the same user is
2^(16-a). "
I prefer the above sentence could be
" For 'a' > 0, 'A' MUST be
larger than 0. This ensures that the algorithm excludes the
system ports. Smaller
values of 'a' excludes a larger initial range; e.g. 'a' = 4, will
exclude ports 0 - 4095. The interval between initial port numbers
of successive contiguous ranges assigned to the same user is
2^(16-a). "
#3. In Fig.7 of sec. 5.3,
“ +----------+ +------------+
|IPv4 sufx| |Port-Set ID |
+----------+ +------------+ ”
I prefer the above ‘sufx’ could to be ‘suffix’.
#4. In sec.6,
“ The PSID field is left-padded to create a
16 bit field. For an IPv4 prefix or a complete IPv4 address, the
PSID field is zero.”
Q. Does the about ‘zero’ means the value of the PSID=0x 00, or the length
of the PSID is zero? I guess it means the former, right?
#5. In Fig.8 of sec.6,
“The Interface identifier format of a MAP node is described below.
| 128-n-o-s bits |
| 16 bits| 32 bits | 16 bits|
+--------+----------------+--------+
| 0 | IPv4 address | PSID |
+--------+----+-----------+--------+ ”
I think BR does not need to use the above IID. I prefer to replace the word
‘MAP node’ to be ‘MAP CE’. Right?
The above format looks like ‘128-n-o-s =64, but that is not always true. I
prefer the IID format of MAP CE could be:
| 128-n-o-s bits |
| <=16 bits| 32 bits | 16 bits|
+--------+----------------+--------+
| all 0s | IPv4 address | PSID |
+--------+----+-----------+--------+ ”
#6. In sec. 8.1,
“ Secondly, the node extracts the source IPv4
address and port from the IPv4 packet embedded inside the IPv6
packet. If they are found to be outside the acceptable range, the
packet MUST be silently discard and a counter incremented to indicate
that a potential spoofing attack may be underway.”
I guess the better to substitute the above word ‘embedded’ could be
‘encapsulated’, right?
#7. In sec. 11
“ They cannot
exist with MAP because each BRs checks that the IPv6 source
address of a received IPv6 packet is a CE address based on
Forwarding Mapping Rule. ”
I think BRs check that the IPv6 source address of a received IPv6 packet is
a CE address based on Basic Mapping Rule, and check that the IPv6
destination address of a received IPv6 packet is a CE address based on
Forwarding Mapping Rule, right?
Best Regards,
Leaf
-----Original Message-----
From: Softwires [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Monday, November 24, 2014 3:39 PM
To: [email protected]
Cc: [email protected]
Subject: [Softwires] I-D Action: draft-ietf-softwire-map-12.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Softwires Working Group of the IETF.
Title : Mapping of Address and Port with Encapsulation
(MAP)
Authors : Ole Troan
Wojciech Dec
Xing Li
Congxiao Bao
Satoru Matsushima
Tetsuya Murakami
Tom Taylor
Filename : draft-ietf-softwire-map-12.txt
Pages : 32
Date : 2014-11-23
Abstract:
This document describes a mechanism for transporting IPv4 packets
across an IPv6 network using IP encapsulation, and a generic
mechanism for mapping between IPv6 addresses and IPv4 addresses and
transport layer ports.
The IETF datatracker status page for this draft is:
<https://datatracker.ietf.org/doc/draft-ietf-softwire-map/>
https://datatracker.ietf.org/doc/draft-ietf-softwire-map/
There's also a htmlized version available at:
<http://tools.ietf.org/html/draft-ietf-softwire-map-12>
http://tools.ietf.org/html/draft-ietf-softwire-map-12
A diff from the previous version is available at:
<http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-12>
http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-12
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
<ftp://ftp.ietf.org/internet-drafts/> ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
Softwires mailing list
<mailto:[email protected]> [email protected]
<https://www.ietf.org/mailman/listinfo/softwires>
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
