Re: tsv-dir review of draft-ymbk-aplusp-08
Pasi Sarolahti wrote: My comments are as an implementer of a port restricted IP. * The typical initial scenario probably is that an A+P gateway is NATing the traffic to a legacy host in private address realm, but I understood that if a host/application supports A+P, it could use A+P addressing directly without NAT. That's the proper way to use of port restricted IP with the end to end transparency not unnecessarily combined with legacy NAT. Have you thought how this would be reflected on the socket API? For example, what would be the intended behavior, if an application tries to bind a port that was not part of the port range assigned for the host? It's like specifying a source address not belonging to the host. So, a super user should be allowed to do so with raw IP. Apparently it is thought that there would be some extended API for an A+P-aware application to query which ports are available, right? My implementation of PRIP has such mechanisms as ioctl. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
tsv-dir review of draft-ymbk-aplusp-08
Hello, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. I found no major issues with the document, and the document is ready for publication. Below are some minor nits you might want to consider addressing before publishing: * Section 1.1: You could add reference to UPnP/NAT-PMP. * Bottom of page 16: you could describe with a few words what delayed translation is. (is it address translation that doesn't happen at the edge of the A+P subsystem?) * Section 5.2: There is a general observation that the more demanding customer uses around 1024 ports when heavily communicating. -- on what is this based on? Do you have some reference or other data to back this up? * The typical initial scenario probably is that an A+P gateway is NATing the traffic to a legacy host in private address realm, but I understood that if a host/application supports A+P, it could use A+P addressing directly without NAT. Have you thought how this would be reflected on the socket API? For example, what would be the intended behavior, if an application tries to bind a port that was not part of the port range assigned for the host? Is there an error, or does that trigger some other behavior? You might want to mention something about such API interactions in some appropriate place (maybe in 5.3.4?). Apparently it is thought that there would be some extended API for an A+P-aware application to query which ports are available, right? - Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Review of draft-ymbk-aplusp-08
Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Tuesday, January 25, 2011 1:51 PM To: Tina Tsou Cc: ops-...@ietf.org; sec...@ietf.org; draft-ymbk-apl...@tools.ietf.org; i...@ietf.org; ietf@ietf.org Subject: Re: Review of draft-ymbk-aplusp-08 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. and which are you? can't be ops, as you are a vendor. so security? but we already received the security review. [Tina: I know the author is my friend Randy, so I have to be very careful ;-) I'm a member and also the secretary of Operations directorate. Here is the wiki page for the Operations directorate. http://trac.tools.ietf.org/area/ops/trac/wiki/Directorates You can see many of us do not have the affiliation of operators. I did the additional review besides the allocated member's review. I'm also a member of Security directorate. I did the additional review besides the allocated member's review. Hope it clarifies. ] but thanks for the review anyway. randy, a bit confused ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-ymbk-aplusp-08
I'm a member and also the secretary of Operations directorate. the ops dir is a joke. does reviews for an area director who does not do his/her own? there is an ops cabal that meets at ietf and has ML etc. all actual ops except for one guest, the actual ops director, ron. http://trac.tools.ietf.org/area/ops/trac/wiki/Directorates You can see many of us do not have the affiliation of operators. welcome to the ietf I'm also a member of Security directorate. must be fun. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Review of draft-ymbk-aplusp-08
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
Re: Review of draft-ymbk-aplusp-08
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. and which are you? can't be ops, as you are a vendor. so security? but we already received the security review. but thanks for the review anyway. randy, a bit confused ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
