Marc, While waiting for WG version of the problem statement to appear, I gave additional review to the DNS section. I recalled the DNS64 and AAAA synthesis topic I discussed in last IETF with some people, and I also sent a related question to Behave WG. According to discussion in behave list, the DNS64 draft will likely take a note of behavior in host multihoming case, but probably you should also add some DNS64 specific notes to mif problem statement, like: -- 6. H1 requests AAAA record from a DNS server on a network that uses protocol translators and DNS64 [DNS64]. If the H1 receives synthesized AAAA record, it is quaranteed to be valid only on the network it was learned from. If the H1 uses synthesized AAAA on an network interface it is not valid on, the packets will be dropped by the network. [DNS64] draft-ietf-behave-dns64-00 -- Best regards, Teemu >-----Original Message----- >From: mif-bounces at ietf.org [mailto:mif-bounces at ietf.org] On >Behalf Of Savolainen Teemu (Nokia-D-MSW/Tampere) >Sent: 22 June, 2009 14:47 >To: marc.blanchet at viagenie.ca >Cc: mif at ietf.org >Subject: Re: [mif] [Fwd: I-D >Action:draft-blanchet-mif-problem-statement-01.txt] > >Hi Marc, > >My opinion is for a) as well. > >Some comments to I-D: > >- Reference of [I-D.savolainen-6man-fqdn-based-if-selection] >(in references and also in chapter 4) is to an old version, >please change in next revision to: >draft-savolainen-mif-dns-server-selection (February 2009). > >- 3.3. Says mobility etc. mechanisms are not required. Would >it add clarity if this would describe that the host may >implement mobility technologies, and for MIF those may or may >not show as virtual interfaces? The particular case I'm >thinking is that if a multi-homed host is running DSMIP6 it >would result in one new interface (addresses) MIF needs to >choose from. E.g. a new flow could be created from the >physical IP address (the same DSMIP6 is using as CoA) or by >using the HoA. Maybe:"If a host implements additional mobility >or multihoming protocols, those may be seen as additional >virtual interfaces, IP addresses, to choose from." ? > >- 4.1. 3-case: even if the IP address learned from S2 would be >for "physically" correct destination server, the server may be >configured to provide different set of services for >connections coming from Internet or Intranet. I mean this >problem may be a security problem, but it may also be service >reachability problem. > >- What about following two additions to 4.1: > >4. S1 or S2 has been used to resolve "a.private.example.com" >to an RFC1918 address. Both N1 and N2 are RFC1918 addressed >networks. IPv4 source address selection may face challenges, >as due address overlapping the source/destination IP addresses >do not necessarily provide enough information for making >proper address selection decisions. > >5. H1 has filled its DNS cache from information received from >S1. H1 opens network connection to N2, which becomes more >favored interface. However, the information learned from S1 >may not be valid on communications inititated over N2. > >Best regards, > > Teemu > >>-----Original Message----- >>From: mif-bounces at ietf.org [mailto:mif-bounces at ietf.org] On Behalf Of >>ext Marc Blanchet >>Sent: 05 June, 2009 21:56 >>To: mif >>Subject: [mif] [Fwd: I-D >>Action:draft-blanchet-mif-problem-statement-01.txt] >> >>Hello, >> new version of the draft, _trying_ to capture most of the >comments on >>the mailing list, bof, etc... Please comment. >> >>one of the discussions among authors is the following: >>- is MIF scope restricted to: >>a) one or more administrative domains >>b) more than one administrative domains. >> >>My own opinion is b), while my co-author is a). >> >>Marc. >> >>-------- Message original -------- >>Sujet : I-D Action:draft-blanchet-mif-problem-statement-01.txt >>Date : Fri, 5 Jun 2009 11:45:01 -0700 (PDT) De : >>Internet-Drafts at ietf.org Répondre à : internet-drafts at ietf.org Pour : >>i-d-announce at ietf.org >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> Title : Multiple Interfaces Problem Statement >> Author(s) : M. Blanchet, P. Seite >> Filename : draft-blanchet-mif-problem-statement-01.txt >> Pages : 12 >> Date : 2009-06-05 >> >>A multihomed host receives node configuration information >from each of >>its access networks. Some configuration objects are global to the >>node, some are local to the interface. Various issues arise when >>multiple conflicting node-scoped configuration objects are >received on >>multiple interfaces. >>Similar situations also happen with single interface host >connected to >>multiple networks. This document describes these issues. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-blanchet-mif-problem- >>statement-01.txt >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >> >> >>-- >>========= >>IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn >>server for VoIP NAT-FW traversal: >>http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca >> >> >_______________________________________________ >mif mailing list >mif at ietf.org >https://www.ietf.org/mailman/listinfo/mif >
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.