I reviewed the document draft-ymbk-aplusp-08 in general.
Operations directorate and Security directorate reviews are solicited
primarily to help the area directors improve their efficiency, particularly
when preparing for IESG telechats, and allowing them to focus on documents
requiring their attention and spend less time on the trouble-free ones.
Improving the documents is important, but clearly a secondary purpose.
A third purpose is to broaden the OpsDir reviewers' exposure to work going
on in other parts of the IETF.
Reviews from OpsDir/SecDir members do not in and of themselves cause the
IESG to raise issue with a document. The reviews may, however, convince
individual IESG members to raise concern over a particular document
requiring further discussion. The reviews, particularly those conducted in
last call and earlier, may also help the document editors improve their
documents.
-----
This document is well written, though there may be some nits.
Comment #1:
In Abstract section this draft proposes an IPv4 address sharing scheme,
treating some of the port number bits as part of an extended IPv4 address.
A SOHO CPE (A+P) may provide with website service. When a host in external
network accesses this website, what information that DNS servers feedback to
host? If it is an IP address, it can't uniquely identify the CPE. If it is
IP + port range, how can host recognize this and process? If it is IP + some
a Port, how can DNS server know when port changed?
Some Operators identify services by five elements include UDP/TCP well-known
ports when CPE is an unreliable device. If well-known ports changed, service
can't be recognized.
Comment #2:
Abstract section,
"In the face of IPv4 address exhaustion, the need for addresses is stronger
than the need to be able to address thousands of applications on a single
host."
- This viewpoint is not always true. During the transition from IPv4 to
IPv6, some set of operators do not want the services are affected, which may
result some customers lost. A smoothly transition technology is more
favorable.
Comment #3:
Section 1.1 says: Another issue with CGN is the trade-off between session
state and network placement.
- If there are too many session state to keep, two CGN or more can be
placed. A distributed CGN may be a good choice. And single point of failure
can be resolved
Comment #4:
In section 3.3.1, it says: different port-ranges can have different
lifetimes, and the CPE is not entitled to use them after they expire what is
the appropriate lifetime for a port-rang? When for P2P application, many
ports are used. In a short-term period, when for some fixed service (e.g.
site), a port may be used for many years. Will the server allocate port
according application? Or else there is some security problem or port
efficient allocation. For the more, port allocation will make more burdens
for server because of large number s of ports and high frequency
requisition.
Comment #5:
SMAP (stateless A+P Mapping) is proposed in section 4.1, IPv4 address and
port is embedded in the IPv6 address ? which would be used to create a
tunnel.
- In section 5.2, ?Dynamic Allocation of Port Ranges? is proposed. What if
the allocated ports do not belong to a single IP address? The SMAP mechanism
may not work in this case.
- The IPv6 address would follow the format defined in
[I-D.ietf-behave-address-format], but port is not included in the address
formats defined by that draft. Any plan to define the address format?
Here is the format defined in [I-D.ietf-behave-address-format]:
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|PL| 0-------------32--40--48--56--64--72--80--88--96--104---------|
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|32| prefix |v4(32) | u | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|40| prefix |v4(24) | u |(8)| suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|48| prefix |v4(16) | u | (16) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|56| prefix |(8)| u | v4(24) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|64| prefix | u | v4(32) | suffix |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|96| prefix | v4(32) |
+--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 1
Comment #6:
In section 5.1.2 A+P for Mobile Providers
- If A+P is implemented in a terminal device, e.g. mobile phone and PC,
there might be some problems, e.g. ARP problem ? terminal would not be able
to send packets to other terminals sharing the same IP address with itself.
- Any thoughts about the solution? A new NAT layer between the IP and
TCU/UDP layer in the stack?
Comment #7:
Section 5.2, it says: mechanism can allocate a port range from another IP
within the same subnet.
- For example, an internal host1 communicate with an external host2. At
first CPE allocates IP1 and a port for some a session. During the
communication, more sessions are built and there are no more ports in IP1.
If IP2 is used for session, the packet may be discarded by host2.
There may be some errors. Where does 198.51.100.3 come? I can't find it in
Figure 15.
Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf