Bob Hinden wrote:
> I would like to hear from the working group on how we should proceed.
I
> think the choices are:
I vote for B, but C would also be acceptable. My reasoning is that they
are deployed and will continue to be used until a replacement is
available. Choosing A means that might no
Brian Carpenter writes:
> I'd go a bit further. I messed around with a large bridged
> network for some years, and this included messing with ARP
> proxies and all the troubles they cause. Basically, making
> a level 2 device simulate level 3 functions is a kludge, and it
> gets even worse when at
Jaya,
Since the default route (::/0) is in the table you list below, every destination
address will match an entry in the table. The address in your example matches the
second row, so the precedence would be 40.
Also, prefixes are more general than address types so you can express more granul
> This is a IPv6 working group last call for comments on advancing the
> following document as an Informational RFC:
>
> Title : IPv6 Node Requirements
> Author(s) : J. Loughney
> Filename: draft-ietf-ipv6-node-requirements-04.txt
> Pages :
Itojun writes (in response to Michael Hunter):
> >This looks like a strong draft. Several issues exist though.
> >
> >1) There is no mention of RFC 3041 (privacy enhanced) addresses.
Both
> >the issue as to if they should be responded with and if they should
be
> >responded to needs to be address
I agree with Michel, and hence in a way I guess I object to the
wording of the question.
Per Margaret's clarification
> People who spoke at the mike, but did not express
> an opinion during the show of hands, may express their YES/NO opinion
now
> on the list.
I'm still entitled to give a respons
> From: Erik Nordmark [mailto:[EMAIL PROTECTED]
>
> > I think the above paragraph is unneeded and confuses the issue.
> > Setting the flags to 0 will restore the system default behavior.
> > If the app is using multiple values at different times, the behavior
> > is really up to the app, and the is
I've read this document, and I would like to see it accepted as
a WG document and charter item.
Comments on the current text:
Section 3
> It is recommended that the application does a getsockopt() prior
> calling to setsockopt() call so that it can save the existing
> source address preference va
Just trying to catch up on email... a few comments below.
I've already seen other people answering most questions in the
same way I would, so (as another individual who supports this
draft going forward) I'll concentrate on responding to other
points.
Margaret writes:
> I think that it should be
> From: Kristine Adamson [mailto:adamson@;us.ibm.com]
>
> I have a question about the tcpListenerEstablished MIB object in the
June
> 2002 version of the new RFC2012 MIB draft. Is this counter only
supposed
> to represent the number of connections that have transitioned to the
> established state
> > > >>From: Brian Haberman [mailto:[EMAIL PROTECTED]]
> > > >>
> > > The more I think about it, the more I realize that
"automagically"
> > > creating the subnet-local scope zone id isn't going to work.
> > > Especially with multiple prefixes per interface.
> > > >>>
> > > >
> > > >
> -Original Message-
> From: Brian Haberman [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 09, 2002 1:48 PM
> To: [EMAIL PROTECTED]
> Subject: Re: IPv6 subnet-local addresses and
draft-ietf-ipngwg-addr-arch-
> v3-10.txt
>
> Dave Thaler wrote:
> >
> From: Brian Haberman [mailto:[EMAIL PROTECTED]]
> >> The more I think about it, the more I realize that "automagically"
> >> creating the subnet-local scope zone id isn't going to work.
> >> Especially with multiple prefixes per interface.
Why not? Can you elaborate?
Shouldn't it always be tru
> From: Robert Elz [mailto:[EMAIL PROTECTED]]
[...]
> | I don't understand how not doing DAD relates to DIID. I thought
> | (possibly mistakenly) that the proposal that Steve Deering presented
was
> | to do with eliminating the delay introduced DAD for addresses that
are
> | unlikely to conflict
> From: Greg Daley [mailto:[EMAIL PROTECTED]]
>
> I've been thinking about how we can use MLD to
> determine if anyone else is defending an address using DAD.
>
> The MLD RFC indicates that a node's link-scope multicast
> addresses except all-nodes link-scope must be joined
> using MLD.
>
> Sinc
> From: Margaret Wasserman [mailto:[EMAIL PROTECTED]]
[...]
> I'm not talking about the limited way in which the "subnet-local"
> multicast scope works today, but about the definition of a subnet.
>
> The word "subnet" means a group of nodes that share a common global
> prefix, including subnet I
> From: Charles E. Perkins [mailto:[EMAIL PROTECTED]]
[...]
> As I wrote before, but perhaps buried in other text,
> I think that IP should only be concerned about the
> "subnet-local" concept, not the "link-local" concept,
> if we are to use those terms as distinguishable concepts.
> When the lin
> -Original Message-
> From: Margaret Wasserman [mailto:[EMAIL PROTECTED]]
[...]
> So, while you indicate that a link-local address may not be able to
> reach all nodes on a subnet, isn't it also true that a subnet-local
> address may not be able to reach all of the nodes on a link?
Since
> From: Rami Lehtonen [mailto:[EMAIL PROTECTED]]
[...]
> There was also some discussion at MAGMA working group that if the edge
> router starts to filter MLD Reports coming from a host (host
> authorization),
> it would be nice to notify the host that such filtering is applied,
e.g.
> with ICMPv6
I had a comment on the ICMPv6 spec which I mentioned to Steve Deering in
Yokohama
and promised I'd also send to the list:
I'd like to see an ICMPv6 error message value assigned for the case
where a node would
need to send a packet from a specific address, but cannot because that
address is
anycas
> -Original Message-
> From: Markku Savela [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 11, 2002 10:17 AM
> To: [EMAIL PROTECTED]
> Subject: Re: IPv6 Scoped Addresses and Routing Protocols
>
> Well, I've not yet fully gotten into issue of getting site local
> addresses from the name s
> Proposed new wording:
>
>Rule 7: Prefer public addresses.
>
>If SA is a temporary address and SB is a public address, then
prefer
>SA.
[...]
The rest of the line after "Rule 7" doesn't match the rest of the text.
The rest of the new wording looks fine to me.
-Dave
-
> -Original Message-
> From: Pekka Savola [mailto:[EMAIL PROTECTED]]
[...]
> On Mon, 10 Jun 2002, Alain Durand wrote:
> > Today, with IPv4+NAT on my home network, I simply point my
> > stub-resolvers to my ISP DNS resolver. It's simple, and works
> > fine, at least until I try to do rever
> From: Bill Fenner [mailto:[EMAIL PROTECTED]]
[...]
> >Yes, scopes have to be convex. This is not new in IPv6.
> >See section 7 of the IPv4 scoped multicast RFC (2365).
>
> The worry is that people might look at routing protocols mechanisms
> that keep the site convex wrt site-local addresses a
> -Original Message-
> From: Bill Fenner [mailto:[EMAIL PROTECTED]]
[...]
> It's fairly clear how to allow A and F to not advertise site-local
> addresses across the boundary (at least, as long as it coincides with
a
> routing protocol boundary, e.g. OSPF area). However, if H1 knows that
Robert Elz writes:
> ps: don't we already have a way to tell from RAs which prefix is
multi-
> link
> and which is not
No. In fact, I would expect that if any prefix is multilink, then all
of them should be.
> (because it matters to whether we send packets to routers
> of just do ND for them
ch of two separate home agents, without adding any additional
work for each home agent, right? It's also non-obvious to me
why it's too much work if there's multiple home addresses
at the same home agent. Can you elaborate?
-Dave
> Am I missing some good feature that results from m
> -Original Message-
> From: Dr. Subrata Goswami [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, June 01, 2002 8:46 PM
> Cc: [EMAIL PROTECTED]; 'IPng Working Group'
> Subject: RE: [mobile-ip] RE: RFC 2462 DAD optimization
>
> I am just curious about what are the technical differences betwee
As mentioned in email I sent a week or two back, this is
related to the issue of whether a link-local address has to be
unique across an entire subnet, not just a link. Today it's
defined as a "link-local" not a "subnet-local" address. This
means that it is not guaranteed to be unique across
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 22, 2002 4:30 AM
> To: [EMAIL PROTECTED]
> Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third
Genera
> tion Cellular Hosts"
>
> >=> I've never seen that in any spec.
> >I gues
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
> >=> Do you mean that MLD is used for the ALL Nodes mcast
> >address ofr example?
>
> yes.
>
> itojun
No.
RFC 2710 end of section 5:
The link-scope all-nodes address (FF02::1) is handled as a special
christophe preguica wrote:
> What should be the behavior of a router when it receives an IPv6 packet
> with Hop Limit = 0 ?
If it's destined to the router itself, accept it.
Otherwise, drop it, and send the ICMPv6 error if the packet wasn't
multicast.
> Does IPv6 have the same behavior as for I
Keith Moore writes:
> > Well, the original idea was to reserve a bit to indicate that the
> > address is Cryptographically Generaged Address (CGA), basically
> > meaning that
> >
> > if the bit is set, then
> >interface id = low64(hash(PK, stuff)) & mask
> >
> > where
> >PK
Antonio Querubin writes:
> If it is how about just defining mapped multicast addresses already?
[...]
>|80 bits | 16 | 32 bits|
>+--+--+
>|..||
Pekka Savola writes:
> In the abstract, s/the stateful protocol/stateful protocols/ ?
Actually the "stateful" wording needs to be changed anyway, as Ralph
Droms pointed out in SLC.
> In 3.2, Host behaviour of looking up NS record from the reverse of
> site-locals may fail for a couple of reasons
Tammy Leino [mailto:[EMAIL PROTECTED]] writes:
> In regards to MLD, should a node transmit an unsolicited report for a
> multicast address of link-local scope? If so, why?
Yes, except for the link-scoped all-hosts group.
One reason is so switches can see which segments have members and not have
> -Original Message-
> From: Thomas Narten [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 27, 2001 7:44 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: draft-ietf-ipngwg-uni-based-mcast-03.txt
>
> I have question about the references to SSM. In particular, the
> document
> -Original Message-
> From: Erik Nordmark [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 19, 2001 2:44 AM
> To: Dave Thaler
> Cc: Dave Thaler; Erik Nordmark; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: uni-based-mcast and malloc-ipv6-guide
>
> -Original Message-
> From: Dave Thaler
> Sent: Tuesday, September 18, 2001 10:22 AM
> To: Erik Nordmark
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: uni-based-mcast and malloc-ipv6-guide
>
> Erik Nordmark asks:
> > I fail to understand why
Brian Haberman wrote:
> > It would be quite useful to outline a bit more of
> > the problem that needs solving in the introduction.
> > It would also be useful to have a comparision with IPv4
> > (either in the introduction or later in the document).
> > Questions I'd like to see answered is wheth
Erik Nordmark asks:
> I fail to understand why routing might fail. Could you explain?
> I do understand that there is a different probability of allocating
> duplicate
> uni-based mcast addresses should the unicast prefix be assigned to
another
> entity, but this doesn't lead to routing failing un
> -Original Message-
> From: Marshall Eubanks [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 17, 2001 3:40 PM
> To: Thomas Narten
> Cc: Dave Thaler; Erik Nordmark; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: uni-based-mcast and malloc-ipv6-guide
>
There is no contradiction here.
(a) is talking about what nodes SHOULD send.
(b) is talking about what nodes MUST be able to receive.
-Dave
> -Original Message-
> From: Suresh Krishnan [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 17, 2001 2:21 PM
> To: [EMAIL PROTECTED]
> Subject
> -Original Message-
> From: Thomas Narten [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 17, 2001 1:52 PM
>
> > How so? One can renew multicast addresses. (Conceivably an
> > implementation could support the ability to automatically renew
> > multicast addresses as long as the un
> -Original Message-
> From: Erik Nordmark [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 17, 2001 1:11 PM
> To: Dave Thaler
> Cc: Erik Nordmark; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: uni-based-mcast and malloc-ipv6-guide
>
> > > -Or
> -Original Message-
> From: Thomas Narten [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 17, 2001 11:17 AM
>
> > > The last paragraph in section 3 is about lifetimes.
> > > I don't understand what the intended effect is of the statement
> > > since I don't know what the lifetime is
> -Original Message-
> From: Erik Nordmark [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 17, 2001 11:23 AM
>
> > See RFC 2908.
>
> At least that reference is missing from the document.
> But I see a mismatch between the draft and RFC 2908 since the latter
> seems to say that an ap
Erik,
I'll let Brian respond to the editorial comments, but to
quickly answer a few of your questions:
> Will the unicast prefix based addresses ever need to use the
link-local
> prefix?
Need? No, since it could only ever be used for link-local multicast
groups,
and for that scope they don't bu
I agree with Brian.
For ISATAP, dotted-decimal is fine, since it appears at the
end just like for v4-compat and v4-mapped.
For 6to4, it's too problematic to change it, so I agree
it should stay hex.
-Dave
> -Original Message-
> From: Brian E Carpenter [mailto:[EMAIL PROTECTED]]
> Sent:
Jinmei writes:
> > I also prefer eth0 over link12. Using the names used to define the
> zones
> > (either the default interface names or actual zone definitions)
seems to
> be
> > more useful than generating a somewhat arbitrary name and displaying
> that.
> > How is the user supposed to correlat
What's a "logical IPv6 interface" and where is it defined?
If you're using VLANs or whatever else, you can do it
with ifIndex values, and this buys you a lot
(you get the ifStackTable, stats, etc).
I see no advantage to introducing another numbering space
and trying to get people to understand i
> From: Daniel Chuang [mailto:[EMAIL PROTECTED]]
>
> [...] what kind of information
> will be put into the "agent-addr" in the v1 Trap
> PDU in the ipv6-only node?
>
> A couple of options:
>
> 1. SNMPv1 traps are not allowed for ipv6-only node.
>
> 2. modify RFC1157.
>
> 3. any other creativ
> -Original Message-
> From: Francis Dupont [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 15, 2001 10:40 AM
> To: JINMEI Tatuya /
> Cc: [EMAIL PROTECTED]
> Subject: Re: Wrap up and last call: sin6_scope_id semantics
>
> In your previous mail you wrote:
>
>Aside from this
I disagree as well that there's a "majority" (or any sort of consensus) for A,
and it would in fact be my last choice of the four possibilities (counting
implementation
dependent).
I would prefer (in order):
C (flexible)
implementation dependent (what you suggest below)
B (strict)
A (flat)
-
Sreeram Vankadari writes:
> > > now 2000::0/128 becomes the anycast address assigned to that
> interface.
> > > Suppose if there are multiple routers attached to that ethernet
> interface,
> > > and a packet comes with a destination address of 2000::/128 which
> > > router will respond to that pac
Sreeram Vankadari [mailto:[EMAIL PROTECTED]] writes:
> Suppose the ipv6 prefix assigned to an interface is 2000::1234:5678/96.
First of all, RFC 2373 mandates that all 2000 addreses (and most others) are required
to have 64-bit interface identifiers, so the prefix in question would have to be
2
Yes, thanks Dario. The mib team still needs to discuss your comments.
We're hoping for some comments from others as well.
-Dave
> -Original Message-
> From: Dario Accornero [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 02, 2001 5:10 AM
> To: Bill Fenner
> Cc: [EMAIL PROTECTED]; [EMAI
Erik Nordmark wrote:
> > Actually I suggested it as well, so I wouldn't have a problem with
no
> > default. Anyone who wants portable apps would just always set the
> > option, no problem.
>
> The benefit of changing the default would be that applications using
> getaddrinfo could be more addres
Jim Bound:
> we did suggest that there be no default for v6only (in fact I
suggested
> it) and no one on either side wanted that. thinking was even if one
did
> not get their choice then its better to have default for the users.
Actually I suggested it as well, so I wouldn't have a problem with
Itojun writes:
> >Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option
> >
> > Then the IPv6 sockets would have to be explicitly allowed to
accept
> > IPv4 connections. So the programs that use the IPv6 centric way
have
> > to be modified a bit, but the buggy implementations and the
unworka
Several people have expressed interest in doing
interop testing (and mobile IPv6 testing in particular)
in conjuction with the interim meeting in Seattle
(http://research.microsoft.com/ietf-ipv6-meeting/)
The interim meetings next week only run until 17:00 each day.
Thursday evening (May 31), the
Lori Napoli writes:
>If an adminstrator set up the stack to have a hoplimit of x. Does
this
>imply that any application, authorized and unauthorized, can
override
>this value? If the adminstrator only wanted packets sent from this
>stack to route through 10 hosts, an applicatio
Antonio Querubin writes:
> After reading through the responses to this thread it's not clear to
me
> whether there's any consensus for change. I see several issues:
>
> 1. Is the current non-transparency of the API for handling multicast
> addresses sufficiently annoying to warrant fixing 'some
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 04, 2001 5:00 AM
> Subject: Re: Mixed Host/Router behaviour
>
> > | also, since RFC2462 basically assumes single-interface host,
> >Huh?
> >I just re-read the thing, and I can't find any assumption like that
at
> >all.
>
> -Original Message-
> From: Markku Savela [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 02, 2001 4:31 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: multicast IPv4-mapped IPv6 addresses/sockets
>
>
> > If this is not system-specific then it seems that the handling
One quick answer:
> 20. ipAddressOrigin should be a TC (see item 15)
>I don't know what is "random" -
>how does this differ from manual?
Random is very different from manual, and means the
system randomly generated the host id.
Two examples of addresses that use random today:
* RFC 3041
We just missed the I-D deadline, but a new
draft is available that just adds the
consensus recommendation from last IETF:
to recommend site-scoped anycast, but not
to recommend a payload format yet.
http://www.aciri.org/dthaler/dddt/dddt.txt
contains the latest draft.
-Dave
--
> Please send substantive comments to the ipng mailing list, and minor
> editorial comments to the authors. This last call period will end two
> week from today on March 7, 2001.
Since some of my comments to the authors on 1/25
are substantive, and none have yet been addressed,
I'm resending to
Brian Carpenter writes:
> 6to4 is meant to do more than imply it:
[...]
You're right.
> And BTW it isn't a draft; it's an RFC. I don't know if the
> announcement is
> out, because I don't seem to be able to receive email this
> morning, only
> send it, but the authors' 48 hour check on the RFC
I'd like to ask for some general consensus on the following questions:
1) Are "::10.1.1.1" and "::169.254.1.1" legal IPv6 addresses?
(They look like global IPv6 addresses, but aren't globally unique.)
RFC 2373 does not mention any such restriction, and so
implies "yes".
2) Similarly, is
For what it's worth, I agree with all of the editorial
changes proposed.
-Dave
> -Original Message-
> From: Wijnen, Bert (Bert) [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 21, 2001 2:39 PM
> To: [EMAIL PROTECTED]
> Subject: MLD MIB
>
> All,
>
> The MLD MIB is close to being pub
Dirk Ooms writes:
[...]
> > All currently deployed (that I know of) multicast routing protocols
> > employ RPF checks in some form. Roughly, this means that A
> > has to be either on the same subnet as V (in which case all
> > receivers will respond), or else somewhere on the multicast
> > distri
(I just got back from 3 weeks of vacation so apologies
for not replying to this earlier :)
Jari Arkko writes:
[...]
> A multicast group X contains the receivers R1, R2, ... RN.
> The victim node is V - not necessarily anything to do with
> X. The attacker is A. All nodes are different. Now, attac
the correct filter. This can, however, be done with
an ioctl(), and hence for symmetry, both gets and sets are
done with an ioctl.
-Dave Thaler
IETF IPng Working Group Mailing List
IPng Home Page:
Robert Elz writes:
> That is, I think there needs to be a "blackhole" (or unreachable)
> preference as well as "bad" "average" "good" (or low medium high).
[...]
> So, I would suggest allocating that final code as "unreachable",
> with the interpretation by the host that after running the algorith
Title: RE: 6over4 for KAME (FreeBSD)
Brian Zill writes:
> Aren't two interoperating implementations a requirement for Proposed
> Standard?
No, I believe it's a requirement for *Draft* Standard.
-Dave
Title: RE: (ngtrans) An IPv4 anycast address for 6to4<->6bone gateways
This was mentioned in the NGtrans meeting in Pittsburgh,
and no such an anycast address doesn't currently exist.
What would be needed would be to get a prefix short
enough to pass the prefix length filters in the Int
Title: RE: (ngtrans) Re: v4 mapped multicast addresses
Erik Nordmark writes:
> I don't think this is necessary for real applications since they
> presumably know whether they are using to use IPv6 or IPv4 multicast
> before creating the socket.
This is only partially true. A protocol-in
Title: RE: bind(2) ordering constraint
::/ binds IPv6 only.
0.0.0.0/ binds IPv4 only.
They're completely independent.
-Dave
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 03, 2000 9:18 AM
> To:
Title: RE: bind(2) ordering constraint
Platform: Windows
Version: 2000
Comment: Output is identical to Itojun's netbsd output, except in
two cases where multiple error codes apply and Windows
chooses to generate a different one.
starting tests, socktype = SOCK_DGRAM
w
Title: RE: IPv6 -over-IPv4 tunnel.
Yes, that was one of the intents of RFC 2667.
-Dave
-Original Message-
From: shankar [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 02, 2000 8:29 AM
To: [EMAIL PROTECTED]
Subject: IPv6 -over-IPv4 tunnel.
Hi folks,
cant we treat the I
Title: RE: TCP Connection Identifiers in IPv6
This can be true in IPv4 as well... for example,
if the IPv4 stack allows multiple interfaces to have
the same "autonet" (169.254...) addresses, which
are roughly equivalent to link-local addresses.
-Dave
-Original Message-
From:
interface indices.
-Dave
-Original Message-
From: Steve Deering [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 29, 2000 9:27 PM
To: Dave Thaler
Cc: [EMAIL PROTECTED]
Subject: RE: rfc2553bis comments
At 9:52 AM -0700 6/27/00, Dave Thaler wrote:
>I really don't like the
Title: RE: rfc2553bis comments
Steve Deering replied:
> At 4:42 PM -0700 6/29/00, Dave Thaler wrote:
> >For example scop 4, being smaller than site-local scope,
> >should use the site-local scope ids. If you're
> >in multiple sites, you can't assume all
u are not a boundary for any larger scope level)."
-Dave
> -Original Message-
> From: Steve Deering [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 29, 2000 4:29 PM
> To: Richard Draves
> Cc: Dave Thaler; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PRO
Title: FW: rfc2553bis comments
Looks like the last try went out as HTML.
Resending, sorry for duplicate.
-Dave
-Original Message-
From: Dave Thaler
Sent: Tuesday, June 27, 2000 9:53 AM
To: Francis Dupont; Steve Deering
Cc: [EMAIL PROTECTED]
Subject: RE: rfc2553bis comments
Title: RE: rfc2553bis comments
Steve Deering writes:
> if the local indexes for the interfaces plus all zones
> (i.e., links,
> sites, and any additional multicast zones configured on
> the node) are
> given distinct values out of the same scope_id space,
> and if one
Title: RE: rfc2553bis comments
Francis Dupont writes:
> If you don't do IPV6_MULTICAST_IF, the meaning would
> be to send via some interface in the set identified by scope_id.
>
> => some = one, all, any subset? This needs some clarifications of
> the scope is not the link-loc
Title: RE: rfc2553bis comments
Francis Dupont writes:
> => I don't believe we should specify two different interpretations
> but obviously we have to do the choice between:
> - use interface indexes and make scope IDs not very useful for the
> receiving side
> - use traditional (ie
socket
>
> => with the traditional behaviour the last point must be done by the user
>
>I don't think this is really a practical example, but IMO, this type
>of behavior is allowed in IPv4 (i.e. bind once, and call
>IP_ADD_MEMBERSHIP multiple
I just got a bounce message from the first time,
apologies if this is a duplicate.
-Original Message-
From: Dave Thaler
Sent: Wednesday, June 21, 2000 5:44 PM
To: Richard Draves; Francis Dupont
Cc: [EMAIL PROTECTED]
Subject: RE: rfc2553bis comments
> > Another point en p
Title: rfc2553bis comments
Comments on draft-ietf-ipngwg-rfc2553bis-00.txt
(and on the POSIX spec by extension...):
1) It would be very useful to be able to obtain (via getaddrinfo) the
list of local addresses to which you can bind. There's at least two
ways I can think of to pote
92 matches
Mail list logo
