2011/8/18, Nejc Škoberne <[email protected]>: > Dear Gang, > >> That is not practicable. You can't do such modification on innumerable >> hosts. > > Who says only "innumerable" hosts will want to have this? My view on this > is, > that these proposals are not meant to solve only a specific > problem for a specific scenario. Why would we want that? If we do proposals > this > way, we will lost ourselves among very similar but a bit different > standards. > It's more complex to "administer" such set of standards and it is much > harder > for the developers to crawl through all these documents in order to > implement > what they need.
"NOT PRACTICABLE" has two meanings. 1) Restricted port aware host is relatively few case 2) Socket need to be modified. That is a practical challenge, not only bind() but also connect() >> Sorry. I still can't see much benefits from that. > > I'll try harder to deliver possible real-world scenarios: > > 1. Home Torrent node. > --------------------- > > I am a customer of an ISP who deployed one of the A+P mechanisms. I have a > home > server which is also able to run Torrent client. And since this is a new > server, > it happens to support the A+P mechanism of the ISP. So I can plug it > directly > to my ISP-provided link (modem, CPE, switch, whatever), and everything /just > works/. This way: > > - I don't have to deal with static RFC 1918 addressing, > > - I don't have to deal with static NAT configuration on the CPE, > > - I don't have to deal with with additional port configuration on my Torrent > box. > > - ... > > It just works. > > 2. Enterprise server mode. > -------------------------- > > I am a network/system administrator for my company, which has a very limited > set of public IPv4 addresses. But as I don't want to maintain a separate > IPv4 > addressing infrastructure in my network, my server network will be IPv6-only > as well. However, the servers still need IPv4 connectivity, and for that I'd > like to use A+P. This way: > > - I don't need any special ALGs for my servers, which I would have to > develop > first since I am using my own proprietary protocols, which can't traverse > NATs > well, > > - I don't need to maintain IPv4 in my network where I don't want to have it, > especially I don't need to maintain _another_ IPv4 addressing (RFC 1918), > > - I get rid of stateful NAT44 in the core, which is very difficult to make > highly available properly (state synchronization). > > - ... > > ---- > > Can you see the benefits now? The consumption is to produce a brand-new network. If that is the case, I may prefer going to native IPv6 network. Gang _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
