On 1/30/13 10:52 AM, "Tom Taylor" <[email protected]> wrote:
>On 30/01/2013 9:56 AM, Rémi Després wrote: >> >> Le 2013-01-30 13:47, Ole Troan <[email protected]> : >> >>> Tom, >>> >>> [...] >>> >>> >[Ole said:] >>> I'm fine with fixing a to 4. >>> if an end user needs well known ports, give her a full address. >> >[Rémi said:] >> An alternative is possible that >> - permits ISPs that want it to assign well-known ports to some >>privileged users without necessarily giving them full IPv4 addresses; >> - uses a trivially simple algorithm. >> >> That which has been chosen for 4rd can be used for MAP-E as well. It >>uses for this an option to be used if well-nown ports must be assignable. >> >> It is specified in two sentences, in >>http://tools.ietf.org/html/draft-ietf-softwire-4rd-04#page-15, at the >>end of the first paragraph. >> Its complete picture representation is in a part of Figure 5: >> >> (by default) (If WKPs authorized) >> : : : : >> +---+----+---------+ +----+-------------+ >> Ports in |> 0|PSID|any value| OR |PSID| any value | >> the CE port set +---+----+---------+ +----+-------------+ >> : 4 : 12 : : 16 : >> >... > >OK, this explains the bit about system ports in the text, when a = 0. >The one objection I see to that is again the matter of address >dependency -- the system ports are available only for the first few >PSIDs, the PSIDs appear as part of the MAP endpoint prefix, so the >prefix value becomes constrained. > >Since devices requiring system ports are likely to be servers, the full >address solution makes sense on another level too. I agree, that a full address for servers running in a map domain makes the most sense. However, since all the well known ports are defined to be < 1024, it seems that it is advantageous to exclude just that range. The draft says "To simplify the port mapping algorithm the defaults are chosen so that the PSID field starts on a nibble boundary and the excluded port range (0-1023) is extended to 0-4095." How important is to have the PSID start on a nibble boundary? There are already a lot of bit manipulations involved, I don't see it hard to implement in a non-nibble boundary. Thanks Senthil > >Tom Taylor >_______________________________________________ >Softwires mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
