[EMAIL PROTECTED] said:
> > |5. Source Address Selection
> > |
> > | The source address selection algorithm produces as output a single
> > | source address for use with a given destination address. This
>
> Yes, that is clear (the algorithm must have only one destination), but the
> ques
I'm slightly confused about the following wording in section 4 of the
default address selection draft:
If an application or upper-layer specifies a source address that is
not in the candidate set for the destination, then the network layer
MUST treat this as an error. The specified source
> >If an application or upper-layer specifies a source address that is
> >not in the candidate set for the destination, then the
> > network layer
> >MUST treat this as an error. The specified source address may
> >influence the candidate set, by affecting the choice of outgoing
>
[EMAIL PROTECTED] said:
> The default route would always be known and PPA to send to simply from
> RAs, if nothing else were known by the end node.
Jim, I'm sorry, I don't understand what you're saying. Can you rephrase
it?
>
> Are you suggesting a change to ND or to configuration of the networ
[EMAIL PROTECTED] said:
> >Ok, I agree that this would be the common case in an IPv6 only
> >network. If a random dual stack box that has IPv6 enabled is
> >placed in a random network out there, the common case today is
> >that it has no IPv6 default router, and this ND rule would be
> >problem
[EMAIL PROTECTED] said:
> >>I don't understand how can flags to getaddrinfo(3) affect source
> >>address selection. where does it take effect in the following code?
> >getaddrinfo implementation itself? of course, then libc would have to
> >aware of src addresses and such..
>
> ge
YES -- Deprecate site-local unicast addressing
-Seb
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Dir
I have some comments on draft-chakrabarti-ipv6-addrselect-api-01.txt.
1. I'm puzzled by the following IPV6_SRC_PREFERENCES settings:
IPV6_PREFER_SRC_TUNNEL /* Prefer tunnel interface as source */
IPV6_PREFER_SRC_NATIVE /* Prefer native IPv6 source addr */
IPV6_PREFER
I have an additional comment on the draft relating to the four new
AI_PREFER_* getaddrinfo() flags (new in version 1 of the draft).
AI_PREFER_SRC_LARGESTSCOPE /* Prefer largest scope */
AI_PREFER_SRC_LOWERSCOPE /* Prefer lower than largest scope */
AI_PREFER_SRC_T
> | My initial though when I
> | saw these preferences was that we should be giving individuals running
> | applications the control, not individuals writing applications.
[EMAIL PROTECTED] wrote:
> There's no way to avoid that. The user (individual running the
> application) can only ever
> Routing header works so that the next hop is always written to destination
> address field and the rest of the path to routing header fields.
>
> Problem with this is that:
> 1) it's impossible to authenticate using AH or the like as the header is
> rewritten all the time
AH has provisions fo
I could probably piece together an answer by going way back in the
mail archives but...
The "Default Address Selection for IPv6" draft's source address
selection seems to prefer addresses of appropriate scope over
"preferred" or non-deprecated addresses. What is the reasoning
behind that?
For e
[EMAIL PROTECTED] said:
> On a given IPv6 Interface on a router, I understand that it is allowed
> to configure a global unicast address with an Interface_ID
> which is *different* from the Interface_ID of the Link Local Address.
>
> - is this something that should be discouraged
> or instead
> -
13 matches
Mail list logo
