Dear Satoru, > We assume that all applications/OSes doesn't aware port restricted > environment.
Sure. > However, there is a case where an application would be allocated a port which > is inside of port set occasionally. Yes. But I am just talking about being open to applications/OSes which _would_ be aware of port restriction. The problem I see with the fact, that you don't do this at the moment, is that in a while, anoter I-D will pop up, filling this very small gap. > The modification of 'to the system call related to bind()' is out of scope in > our draft. Of course. I don't think you should be defining the implementation. I just think that you should leave it open so that if someone is going to implement such a restricted system, he can then connect directly onto the IPv6 network. All other A+P drafts do this, I really can't see a valid reason why you could not do this with "4via6 translation" as well. > IMHO, address mapping rule and port distribution algorithm are the difference. > Let me think that if 4rd is configured with 'DomainIPv6Prefix == > 2001:db8::/32', 'CEIPv6PrefixLength == /72' and 'Domain4rdPrefix == 0/0' for > example. 40bits EA-bits are divided to 32bits IPv4 address part and 8bits > port-set ID part. The length of the port-set ID expresses that address > sharing ratio. The bits pattern of the port-set ID expresses port-set index > of modulo operation, described in the divi. Yes, this is the difference. Xing Li, one of the authors of dIVI, also points out that your draft "lacks the difinition of suffix, therefore is not compatible to IPv4/IPv6 translation RFCs." How do you see this? Anyway, are we sure, that we need two different drafts to cover these differences? I mean, the principle is the same, isn't it? In my opinion, there is an inflation of I-Ds and I think that with some additional synchronization of efforts we could avoid doubling work of each other. But I may be wrong. I think that the same goes for 4rd and SA46T-AS, for example. Thanks, Nejc _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
