Hi, First: I cleared my discuss, so this document's progress is now up to you guys and Joel. Some further discussion inline:
> 4-02-21 0:56 GMT+08:00, Jari Arkko <[email protected]>: >> FWIW, I have now done my own review. I think there are language issues, but >> they do not prevent going forward. Language itself will be fixed by the RFC >> Editor. I'm more interested in cases where there might be an semantics >> unclarity issue. >> >> I think it would be beneficial to go through each of the comments before >> final approval of the document. >> >> With that in mind, going through some of my own and Elwyn's comments: >> >>> o Operators who adopt NAT64-FE may leverage the application layer >>> proxies, e.g. X-Forwarded-For (XFF) >>> [ >>> I-D.ietf-appsawg-http-forwarded >>> ], to convey the IPv6 source >>> address in HTTP headers. >> >> I'd say ... may leverage application layer proxies, and those may use >> additional attributes such as X-Forwarded-For ... > >> >>> Those messages would be passed on to >>> web-servers. The log parsing tools are required to be able to >>> support IPv6 and may lookup Radius servers for the target >>> subscribers based on IPv6 addresses included in XFF HTTP headers. >>> XFF is the de facto standard which has been integrated in most >>> Load Balancers. Therefore, it may be superior to use in a NAT-FE >>> environment. In the downsides, XFF is specific to HTTP. It >>> restricts the usages so that the solution can't be applied to >>> requests made over HTTPs. This makes geo-location problematic for >>> HTTPs based services. >>> >> >> Not sure we should call something a de facto standard while pointing to a >> draft. I'd just say "... has been implemented in many ..." > > thank you for the suggestion. We will make following changes: > > ==NEW > > o Operators who adopt NAT64-FE may leverage the application layer > proxies. Those may use additional attributes such as X-Forwarded-For > (XFF) > [I-D.ietf-appsawg-http-forwarded] to convey the IPv6 source > address in HTTP headers. Those messages would be passed on to > web-servers. The log parsing tools are required to be able to > support IPv6 and may lookup Radius servers for the target > subscribers based on IPv6 addresses included in XFF HTTP headers. > XFF has been implemented in most Load Balancers. Therefore, > it may be superior to use in a NAT-FE > environment. In the downsides, XFF is specific to HTTP. It > restricts the usages so that the solution can't be applied to > requests made over HTTPs. This makes geo-location problematic for > HTTPs based services. OK > > > >>> The experiences of some >>> applications are still align with [ >>> RFC6586]. >> >> >> Not sure what this means. > > Several applications don't work properly as described in the RFC6585. If you use that text, then it would be fine. > >> >> >>> | SIP-VoIP |Fail, due to the lack of NAT64 traversal | >>> >> >> Did you mean ALG? Not sure what this would mean otherwise. > > I mean ICE is recommended to be supported in order to avoid SIP-ALG. > After the discussion with Dan Wing, resorting to SIP-ALG for > supporting IPv4-IPv6 inter-working is not preferred. Ok. Please elaborate, because the text was unclear to the reader. Also, I think you should go through Elwyn's comments and see if you make improvements. Jari _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
