Date: Thu, 1 Jun 2017 20:49:29 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-net@freebsd.org Subject: Ipv6 / DNS questions Message-ID: <759e086e-e6c3-3b3a-1578-834af5adce0d@denninger.net>
next in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
Perusing through the various documentation I've not yet found an answer
to this, and figure someone might know where to point me before I start
banging code beyond a shell script or three.
Assuming we have a "dual stack" system on the Internet; the provider is
willing to allocate us anywhere from a /56 to a /64 off stateless Ipv6
which our gateway (running FreeBSD), and that is working using dhcp6c.
Said gateway then (typically) gets said /56 and allocates a /64 on the
internal interface, and runs rtadvd. The clients run rtsold and are
getting addresses just fine. Windows clients, Android phones and
similar are also having no problems.
Now posit a host "inside" the gateway that I wish to have an exposed
service on the Internet. In the IPv4 world I run NAT, the DMZ'd host is
on a private address, and I port-twist at the gateway (e.g. a connection
to TCP port 5050 on the gateway goes to x.x.x.x:5050 on the internal
host.) The external client is none the wiser; he only sees the single
outside IP. For IPv6 of course the internal address is routable, but
this leads to a problem -- how does the outside guy know where it is?
Is there a dynamic DNS update method associated with Ipv6's address
assignment system? Since the assignment is "stateless" it obviously
(and does, in my experience!) move. I can deal with it via a couple of
shell scripts, and there are only a couple of hosts where it matters,
but this would dramatically simplify the IPv4 gameplaying that's
necessary to have something behind a gateway router while on a "globally
visible", but possibly changing "at whim", IpV6 address.
I assume someone has gone after this issue by now so if there's "prior
art" a pointer would be appreciated.
Thanks in advance!
--
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
[-- Attachment #2 --]
0 *H
010
`He 0 *H
\0X0@=0
*H
010 UUS10UFlorida10U Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA0
161218194535Z
211217194535Z0W10 UUS10UFlorida10U
Cuda Systems LLC10Ukarl@denninger.net0"0
*H
0
͍fd`1ie6";fSz`5¹/?{=Ӵowjħ_fnӴMG\ҢҖ4ib}>@mJo&mM;
Q9U cj]p퐆W.2E=
^¢tzĄ'5i7_`~#dY
`]R]N%R}EXzqV@[oN T>5AwYˡA"\v&YG]+($p:M,T?=mJkMљg*ym
L!J[./d?W^LysD'1
+V'~{-SSX= q-f=%&V<m4BeSet|
l2m 6iO{wv
+aHXˈ5=~é*C!?uJr3tb'3`Oe)üLxt&3N526llU
.|Cp[l? 007++0)0'+0http://cudasystems.net:88880 U0 0 `HB0U0, `HB
OpenSSL Generated Certificate0U/Zi
0GhG0U#0$q}ݽʒm50U0karl@denninger.net0
*H
b%X%gwq
Ɂэr K[DMJ35W6
sz8d|qB2Cyw2PbV}
â[!W{HD7oD.TZ'w6~g( -,]R8P{*[f<1=7jGj9铚~3f2AʺN k~@vz^j(>ͺyh2y{/9}4.45#S|<fW!.,Bss*Q+h=}l@ "q "M&6J5*,G {hɫjbNgǠ.ЃXȶ4$O.5evHlZba!4eE!x|Za1nZ5TuPvW|#G+ DZpI7S'n0 haGa@vZ e|]Cu+))vRyY100010 UUS10UFlorida10U Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA=0
`He M0 *H
1 *H
0 *H
1
170602014929Z0O *H
1B@}yP^/{qu)[`-pC!Cdo ߷FBTzQH;lʋk0l *H
1_0]0 `He*0 `He0
*H
0*H
0
*H
@0+0
*H
(0 +710010 UUS10UFlorida10U Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA=0*H
1010 UUS10UFlorida10U Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA=0
*H
G#>7e<B1尔6Ԍ_ZuSPHI_֖:ClºJF7?7\ͱd,Acr]"0`v'V0,
ji·@ނ *Ok5ש%м;مz(|O=MGH)
j#|T'
Y[e[Y3=]0{oU/
xjT=rrh-lj~ȌW%۩Ypa$sQ-u%1((TkB?' R̐5 ǥvDsovy`
x7jeg{c
}m sO0R"\;F6;x!@̵qQ@*
F2ؤ2$A1$BK$ˠo7-
d݈ ,O^ ^ԤSEx+?!;/an,Z(VI@$5W
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?759e086e-e6c3-3b3a-1578-834af5adce0d>
