> Section 4 > > The above flags are ignored for the AF_INET address family. If a > > returned address is an IPv4 address (either as AF_INET6 when > > AI_V4MAPPED, or as AF_INET) then the source preference flags have > > no effect. > > If someone implements Mobile IPv4, wouldn't the HOME/COA flags > be applicable to IPv4 source addresses?
Others also commented on V4MAPPED addresses. Are you asking whether a Mobile IPv6 stack node would be communicating a MobileIPv4 node ? Currently there is no such transition mechanism for that and I think, perhaps it's simpler if MIPv4 nodes talks to only MIPv4 mobile nodes. But, are you thinking of the case when a dual stack MIPv4 mobile node wants to use AF_INET6 sockets ? Since this API draft is to support address selection RFC, I'd say it's safe to ignore the flags for at least AF_INET socket family. > > Section 7: > > Is there a need for REQUIRE flags in addition to or instead of the > > PREFER flags? Note that in general it isn't possible to verify > > that a requirement can be satisfied until sendto() or connect() > > (when the destination address is known) thus this would result > > in late errors being reported to the application. > > I agree "require" flags would be nice. For example, if an app requires > a particular type of address and there are no such addresses available, > it may be better to fail the setsockopt than either failing all sends or > using another type of address instead. > > If the consensus is go this way, it would be better in my opinion, > to split the socket option into 3 separate options (HOME/COA, > TMP/PUBLIC, and CGA/NONCGA). For each of those three options, > you'd have 5 values: > Require A > Prefer A > Use system default rules > Prefer B > Require B > ai_flags is type int. So one of the concerns is in the limitation of flag bits (assuming there would be atleast 4 flags required for each option above to map into AI* flags). But, if we need to take the scope and require flags into account, perhaps we have to think about the usage of AI_* flags and its scalability. > I also saw a couple of typos/grammar issues which I will just send > to the authors. Got them. Thanks. -Samita -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
